hero-bg

Что такое компьютерная информационная система

category

Внедрение КИС

schedule

22 минуты

Этой статьей я открываю цикл, посвященный взаимодействию между заказчиками (пользователями) и программистами при внедрении программного обеспечения и автоматизации работы. О том, насколько сложно найти общий язык и реализовать успешный проект, думаю, известно практически всем. Скорей всего, и вы можете рассказать печальную историю о том, как “не получилось”. А, может, и не одну.

На собственном опыте я понял одну из важнейших причин неудач - отсутствие взаимопонимания. А в его истоках лежит непонимание людьми базовой терминологии.А потому именно с этого я и начну цикл.

В последующих статьях я поясню, как правильное понимание термина “компьютерная информационная система” почти всегда помогает на практике при внедрении программных продуктов. А после - расскажу о собственном опыте и приведу примеры реализации проектов. 

К написанию этой статьи я шел очень долго, а материалы для нее я уже не первый месяц использую в процессе консультирования своих клиентов. Одна из самых больших проблем в любой сфере деятельности, где используется специфическая терминология, – это договор о понятиях. Часто люди используют слова, вообще не понимая их значения. И трактуют их каким-то своим особенным образом. Результат – отсутствие взаимопонимания, претензии и недовольство результатом. Особенно сложно пояснять основополагающие базовые понятия. Но в сферах бизнеса и IT технологий без этого не обойтись.

Одна из самых распространенных проблем при внедрении IT-систем – очень высокий процент провалов. Внедрение тормозится из-за отсутствия взаимопонимания с программистами, нередко уже готовые программные решения оказываются «пылящимися в коробке», так как они оказались совсем не тем, что ожидал пользователь.

Попытки пояснить и классифицировать компьютерные информационные системы привели к появлению огромного числа сложных и малопонятных терминов. Их пытаются делить на классы и подклассы, описывать странными для широкого круга людей терминами, что приводит к еще большей путанице.

Сложности взаимопонимания с IT-специалистами

Пользователи часто вообще не понимают, кто такие программисты и чего от них требовать. Я и сам в свое время, когда делал первые шаги в IT, с не понимал, что такое компьютерные информационные системы, какую роль в них играют программисты, когда и зачем они нужны.

Примеру: Если вы обращаетесь к врачам или, например, в строительную компанию, вы точно понимаете, что за специалист перед вами, как к нему обращаться, что рассказывать, какого результата ожидать. В IT-сфере до сих пор нет жестко устоявшейся и понятной на уровне обывателя терминологии.

Одна из самых больших проблем в IT – отсутствие общей( именно общей) теоретической базы. Я написал уже много тематических статей, предназначенных для широкого круга читателей. Например, «Что такое CRM» или «Иерархия IT-систем и выбор программного обеспечения для организации труда». Все они призваны в числе прочего помогать мне самому находить общий язык с клиентами. Но и здесь я столкнулся с непониманием. Люди не осознают в принципе, что такое IT система. И объяснить это «на ходу» бывает крайне сложно.

Справочники, учебники и статьи в интернете практически не дают информации на уровне пользователя. Например, определение в Википедии выглядит так:

Информационная система (ИС) — система, предназначенная для хранения, поиска и обработки информации, и соответствующие организационные ресурсы (человеческие, технические, финансовые и т. д.), которые обеспечивают и распространяют информацию (ISO/IEC 2382:2015). Предназначена для своевременного обеспечения надлежащих людей надлежащей информацией, то есть для удовлетворения конкретных информационных потребностей в рамках определённой предметной области, при этом результатом функционирования информационных систем является информационная продукция — документы, информационные массивы, базы данных и информационные услуги.

 

Осмыслить и понять это определение без глубоких знаний в теме практически невозможно, да и вникать в него, по большому счету, бессмысленно. И люди в большинстве своем так и не понимают: что является компьютерной информационной системой, а что – нет. Какие качества обязательны, а какие вторичны. Вопросов очень много. И если вы не будете понимать явления в его сути, вы так и будете понимать его как некую “магию”,шаманство.  

В этой статье я попытаюсь дать определение IT-систем, понятное широкому кругу читателей, на основе собственного опыта и знаний. Конечно, я буду рад любой критике и дополнениям, так как тема – очень объемна и фундаментальна. А существующая на сегодняшний момент информация – сложна для восприятия и несколько противоречива.

Что такое компьютерные информационные системы?

Когда я читал различные определения IT систем, я долго не мог понять, почему они такие разные? Где-то можно встретить нечто громоздкое и всеобъемлющее, как в той же Википедии. А где-то краткие определения, «выхватывающие» какие-то отдельные аспекты и полностью на них основанные.

Как я вижу, суть проблемы в том, что люди не пытаются создать определение, которое стало бы фундаментальным обоснованием. Скорее, прослеживается стремление пояснить их собственное видение. И это я даже не говорю о ситуациях, когда описания и определения связаны с продажей какого-то программного обеспечения.

Чтобы понять, что же это такое, давайте вспомним, как появляется на свет новый программный продукт:

Этап 1. Идея. Просто на уровне «а давайте сделаем что-то, что будет делать вот такие вещи»

Этап 2. Построение модели.

Этап 3. Кодинг. Алгоритм воплощается в реальность в виде программного кода, которым смогут пользоваться люди.

И потому на самом общем уровне любую IT-систему (программный продукт, информационную систему) можно определить кратко:

Идея, выраженная посредством языка программирования. 

 

Почему именно “выраженная”, но не “реализованная”? Потому что компьютерного кода недостаточно для того чтобы идея заработала, получила материальную основу. Для того чтобы появилась материальная основа, необходимо чтобы человек реализовал ее.

Пример: Мы написали компьютерную программу, но чтобы она заработала необходим компьютер который будет ее запускать, монитор который будет при необходимости выводить эту информацию в виде понятном для человека. В конце концов нужен человек который будет запускать ее когда надо, проверять её работу, обслуживать.

На основе этого базового обоснования можно уже детализировать другие особенности, развить и выразить всю проблематику, связанную с информационными системами. Но здесь я считаю, что важна именно суть: появилась идея, которую можно выразить  посредством языка программирования. Было найдено и воплощено в жизнь решение.

Чем поможет понимания особенностей IT систем?

Чтобы правильно выбирать программное обеспечение и понимать, какие дополнительные действия потребуются, стоит отталкиваться от определения «идеи, выраженной в программном коде».

И тогда, первый этап выбора будет основан на идее. Важно понимать, какую именно идею воплощали разработчики. Что они хотели и сумели реализовать. Какие основные принципы они воплощали в жизнь.

Если вы не сумеете понять идею, т.е. предназначения программного обеспечения, то ваши мысли о том, как вы будете использовать программу, не будут совпадать с идеями разработчиков. В итоге вы купите ненужный продукт.

Но чтобы идея информационной системы совпала с вашей, необходимо, чтобы у вас была также собственная идея. Да, она будет выражена на пользовательском уровне. Но она должна быть.

Например, если вы хотите добавить на сайт калькулятор ОСАГО, нет смысла интересоваться просто калькулятором или какой-то системой расчетов других функций. Ваша идея – ОСАГО. Значит, нужно искать, кто из разработчиков также воплощал расчеты по ОСАГО. Иначе доработки выбранного продукта потребуют очень больших усилий либо вообще продукт окажется неподходящим для вашей идеи.

Для крупных информационных систем крайне важно составить список ваших идей. И убедиться, что у разработчиков выбранного программного продукта в момент его реализации также присутствовал необходимый вам перечень идей, и, как следствие, решений.

Второй важный параметр: соответствие идеи ее реализации. Нередко разработчики в процессе воплощения идеи по самым разным причинам, начиная от ошибок и заканчивая организационными решениями уходят от изначальной идеи. И продукт, который должен был воплощать в себе одну идею, реализует ее лишь частично либо не реализует вообще. Это обязательно нужно проверять при помощи тестирования, консультаций со специалистами или какими-то другими способами (отзывы знакомых и прочее).

И третья проблема: идея, которую вам продают, может совпадать с вашей, но не совпадать с идеей, которую вложили в программную систему разработчики. Дело в том, что в коммерческих продуктах (а они в наше время почти все такие) заключается не столько в том, чтобы вы получили нужный инструмент, сколько в том, чтобы продать вам программный продукт. Т.е. при постановке задач разработчикам основная идея заключалась именно в продаже продукта, а не в его качественной работе и соответствии всем вашим потребностям.

Далее «в игру» вступают маркетологи, вы как вам кажется, что вы покупаете как раз ту «идею», которая вам необходима. А на самом деле, вы покупателе продукт, выполненный с другими идеями (продажи). А ваши потребности при реализации будут на уровне идеи только на втором месте. Продукт будет красивым, удобным, особенно на уровне демоверсий. Но в нем может не оказаться важных для воплощения именно вашей идеи инструментов.

Это как покупка квартиры с косметическим ремонтом «чтобы продать» - все очень красиво и качественно, а «баги» выявляются после покупки. К сожалению, в обществе капиталистическом, ориентированном на получение прибыли, такое встречается повсеместно. И частично воплощается даже в самых лучших системах.

Маркетинг и программный продукт

Почему пользователи так редко воспринимают программные системы как «воплощенные идеи»? Я считаю, что здесь проблема заключается в маркетинге. Чаще всего IT-системы подаются разработчиками и воспринимаются пользователями, как материальный товар. Причина такого подхода очевидна – товар продать намного проще, чем идею.

Человеку сложно воспринимать и, тем более, покупать идеи. Их невозможно «пощупать», и продавец редко может пояснить, почему именно такая идея лучше других. Другое дело – IT система как нечто материальное. Здесь сразу речь идет о непосредственной пользе и преимуществах с точки зрения покупателя. Все можно увидеть, оценить, выбрать.

Маркетологи стремятся показать выгоды с точки зрения покупателя. Тем более, что у любой программы есть определенная цена. В результате у покупателей складывается несколько искаженное представление об информационных системах: они считают, что осуществляют покупку готового продукта. Такого же, как сапоги или автомобиль. И часто недоумевают, и разочаровываются, когда понимают, что это не так. Оказывается, для реализации информационной системы понадобятся какие-то доработки, настройки, работа программистов и т.д.

Идея и выбор программной системы

Первое, где поможет понимание особенностей информационных систем, это правильный выбор программного продукта.

Основные критерии выбора:

  1. Ваша идея должна соответствовать идее разработчиков максимально близко по всем параметрам.
  2. Качество реализации идеи в коде должно также отвечать поставленным вами задачам.

Таким образом, для выбора программной системы вам нужно четко сформулировать вашу собственную идею: что должна выполнять информационная система, какие параметры действительно важны (соответствуют вашей основной идее), что – второстепенно (без этого можно обойтись). Все функции программных, которые в ваш перечень не входят, придется изучать отдельно. Иногда они становятся приятным дополнением. Но чаще – ненужными возможностями, за которые вам придется заплатить.

Из всех существующих программных продуктов вас заинтересуют только те, где в описании указана нужная вам идея. В идеале именно ваша идея должна декларироваться как основная, а другой функционал, если он есть, как дополнительные возможности.

Далее следует изучить качество реализации. Для этого используются отзывы других пользователей, тестовые бесплатные версии и т.д. Помните, что реализация далеко не всегда соответствует изначальной идее и описанию.

Нередко при покупке программного обеспечения используется ошибочная тактика. Покупатель изучает, реализованы ли нужные ему функции, не обращая внимания как раз на основную идею разработчиков, даже если она явно прописана в названии и описании программного продукта. В результате они получают нужный функционал, но зачастую в «обрезанном» виде. Систему приходится очень сильно дорабатывать, а это – значительные затраты времени и средств. А иногда это вообще невозможно. При этом в составе продукта покупатель получает множество ненужных ему возможностей, которые он также вынуждено оплачивает.

Например, если вам нужен сайт-визитка, нет никакого смысла покупать дорогостоящий «движок» интернет-магазина. И наоборот, если вам нужен магазин, попытка воспользоваться бесплатной CMS чаще всего ведет к значительным затратам при адаптации этого кода под интернет-магазин.

С одной стороны, даже под бесплатные «блоговые» CMS существуют готовые надстройки для создания интернет-магазина. С другой стороны, это не основная идея выбранного вами продукта. А потому функционал в ней ограничен. И как только вам понадобится интеграция с учетной системой, какой-то обмен данными с CRM и другие функции автоматизированной торговой площадки, вы столкнетесь со сложностями, потеряете время. Да и затраты на доработки часто оказываются выше, чем в случае покупки готового интернет-магазина с уже реализованными возможностями автоматизации.

Очень важно, чтобы выбранный вами программный продукт максимально соответствовал вашей идее.

Как найти общий язык с разработчиком

Понимание сути информационных систем помогает правильно выбрать разработчика для создания или доработок программного продукта. Людям, которые далеки от информационных технологий, часто кажется, что все программисты одинаковы и с ними сложно найти общий язык.

На самом деле, чтобы добиться взаимопонимания с разработчиком, нужно:

  1. Четко сформулировать свою идею. Причем, эта идея должна быть максимально конкретизированной и конкретной. Вариант «я хочу заработать на программе деньги» - это не идея. Идея – это «что я хочу, чтобы делала эта программа». Это может быть ТЗ, может описания в виде диаграмм, брифа.
  2. Убедиться, что разработчик понял суть идеи. Здесь уже вопрос из области коммуникации. Один специалист поймет вас «с полуслова». Другому придется пояснить несколько раз и не факт, что он воспримет все правильно. Чтобы избежать проблем и разночтений, существуют предварительные этапы работы, в том числе, написание четкого и однозначного технического задания. Если вы сумеете получить внятное и соответствующее вашей идее ТЗ, значит, и дальше работа будет выполняться правильно.

Как видите, при правильном понимании термина «компьютерные нформационные системы» коммуникация со специалистами также оказывается не столь сложной, как это описывают многочисленные мифы об «айтишниках».

Подробнее о том, как на практике применять такое определение информационной системы, читайте в следующей статье.

Проверка данных на уровне системы

Aditum nocendi perfido praestat fides (Доверие, оказанное вероломному, дает ему возможность вредить) Греческая поговорка

При разработке компьютерной информационной системы, как и при любой работе с данными, где участвуют две стороны, одна из самых важных задач это проверка подлинности данных. Важно, чтобы участники процесса вносили правильную информацию, и чтобы проверка ее точности не занимала много сил и времени. С этой задачей столкнулись и мы при разработке учетной системы Trinion Торговля .

Описание проблемы

Для лучшего понимания важности этой проблемы, обратимся к примеру. В учетной или CRM-системе работает менеджер по продажам. Каждое событие, связанное с процессом продажи, он фиксирует в информационной системе.

Допустим, что менеджер провел переговоры и в Сделке указал: сумма сделки – 20 000 рублей, товар, который заинтересовал клиента – матрас. 

Таким образом, руководитель видит, на каком этапе Сделка, и может сориентироваться, какую прибыль компания получит в случае ее успеха.

Но как проверить корректность указанных данных? В выполнении задачи внесения сведений о событии участвуют две стороны – пользователь и программная система. От системы вы можете получить только сохраненную информацию, а пользователь на словах может подтвердить, что да, он действительно звонил клиенту, они обсудили продажу, и действительно в этой сделке фигурирует матрас стоимостью 20 000 рублей. Потому эти данные менеджер и указал.

Руководитель, который будет проверять правильность введенных данных, будет вынужден поверить своему сотруднику на слово.

Но здесь возникает проблема:

Если мы не хотим злоупотреблений, мы не должны слепо доверять людям.  

Мы должны точно знать, что введенные данные верны. И человек, который вводит данные, должен точно знать, что указанную информацию в любой момент можно проверить. Тогда у него не будет соблазна злоупотреблять работой в системе. 

О том, как сотрудники злоупотребляют своим положением, я уже писал в статье « 10 способов злоупотребления служебным положением» .

Как обычно проверяют подлинность данных

Самый распространенный метод проверки правильности введенных данных при работе с клиентами – это запись всех телефонных разговоров и последующее их прослушивание. Но это очень трудоемкий процесс.

ВКаждый день менеджер разговаривает со многими людьми. И здесь срабатывают, так называемые, большие числа. Например, у руководителя в отделе 5 менеджеров, каждый из них разговаривает по полчаса. Это значит, что руководителю нужно прослушать 2,5 часа разговоров. При этом каждая минута такого прослушивания в реальном времени занимает не одну, а 2-3 или больше минут. Потому что при прослушивании часто перематывают назад, чтобы уточнить данные, расслышать что-то, что было непонятно и т.д.

Проверять таким образом каждую сделку крайне сложно. А хотелось бы уже в момент запроса сразу получать ответ, насколько введенная информация верна. Потому мы, конечно, фиксируем в своей системе телефонные звонки, понимаем, что это полезная функция, в том числе, для самого менеджера. Но саму проверку рекомендуем реализовать иначе.

Третья сторона для быстрой проверки подлинности данных

Вы уже знаете, что в самом процессе участвует две стороны – система и пользователь. И это создает сложности при проверке правильности указанных данных. Чтобы в случае каких-либо сомнений быстро получить ответ на вопрос, требуется третья сторона.

Правило третьей стороны звучит так:

Для проверки данным всегда необходим тот, кто находится снаружи. 

В данном случае это не система, это не пользователь. А кто тогда? Кто или что еще может подтвердить данные? Самый простой ответ – покупатель.

Чтобы реализовать быструю проверку с помощью третьей стороны, необходимо, в первую очередь, изменить процесс. Пользователь должен не только создавать сделку и фиксировать в ней событие, но одновременно создавать какой-то печатный документ, который будет отправлен по почте покупателю.

И тогда покупатель будет третьей стороной. Как это будет выглядеть? Если есть какие-либо сомнения, что пользователь что-то неправильно ввел в систему, где-то указал неверные цифры, можно просто запросить у покупателя коммерческое предложение.

Также третьей, а, скорее, даже четверной стороной, может выступать почтовая система. Все отправленные письма с коммерческими предложениями хранятся на почтовом сервере. И мы всегда можем посмотреть, что было отправлено, какая сумма указана и так далее.

Таким образом, мы получаем правило:

Если мы хотим в учетной системе, чтобы данные были проверяемы, мы должны привлекать третью сторону, кого-то помимо пользователя и учетной системы. 

При разработке системы Trinion Торговля наши специалисты разрабатывали бизнес-процесс таким образом, чтобы участие третьей стороны можно было реализовать без каких-либо доработок и сложностей. Более того, такая проверка в системе используется по умолчанию. А потому вам достаточно скачать и установить себе систему Trinion Торговля, настроить права пользователей и начинать работу. Защита от злоупотреблений сотрудников уже включена, все виды проверки вы можете использовать. А знание этого факта поможет вашим сотрудникам избегать ненужных соблазнов.

Терминология в IT

Сегодня я хочу поговорить о том, насколько важна терминология в IT и как понимание терминологии влияет на правильность принятия решений.

Те, кто читал меня ранее, знают, что я очень большой процент своих статей посвящаю именно терминологии. Я много писал в свое время об 1С, о CRM и ERM системах, о других типах программных систем и продуктов для бизнеса. И в каждой из статей за исключением, тех, что не были связаны напрямую с IT-тематикой (судебная система, как теряют бизнес и т.д.), я обязательно уделяю максимум внимания терминам, а также простым и понятным широкому кругу читателей определениям для каждого понятия.

Почему я уделяю столько внимания IT терминологии? Зачем ее знание и понимание необходимо бизнесменам?  О том, как понимание терминов влияет на принятие решений и почему без этих знаний крайне сложно наладить плодотворное сотрудничество, я и решил рассказать.

Почему я начал писать статьи с пояснениями терминов?

Лично для меня написание подобного рода статей напрямую связано с моей основной деятельностью. Как бизнес-консультант, я часто предлагаю какие-то IT-продукты и решения для автоматизации бизнеса. При этом нередко оказывается, что мы говорим с заказчиком «на разных языках».

Чтобы пояснить преимущества выбранного мною решения, необходимо, чтобы клиент понимал хотя бы основные принципы работы систем, подобных той, что я предлагаю, а также понимал хотя бы основные термины, без которых говорить о каких-то продуктах IT практически невозможно.

В результате мне приходилось, да и сейчас нередко приходится, простым языком пояснять клиенту сначала – термины и основные принципы работы систем того типа, который я предлагаю внедрять, и только потом можно переходить непосредственно к сути вопроса.

Статьи нередко помогают решить вопрос взаимопонимания и получения базовых знаний заказчиком еще до встречи и обсуждения сути проекта.

«Как вы лодку назовете…»

Специальная IT-терминология используется не только в технических описаниях, но даже в названии программного продукта. Таким образом, разработчики обозначают сразу сферу применения системы. Например, уже по названию Zoho CRM понятно, что это программная CRM-система, т.е. продукт для автоматизации продаж и работы с клиентами.

Аналогично при выборе товаров в магазине, если вы видите на ценнике или упаковке «разводной ключ», вы уже понимаете четко сферу возможного использования этого товара, даже без детального изучения того, что спрятано в коробке. И быстро можете понять, нужен вам в принципе такой товар или нет.

Вторая причина применения терминологии в названиях – это маркетинговые решения. Разработчики стремятся упростить ваш выбор, привлечь максимум внимания к своему продукту. Все понимают, что внимательно изучать и тестировать существующие программные решения от разных компаний можно неделями или даже месяцами.

Также широко известный факт, что первичный отбор товаров, в том числе, в программного обеспечения, производится «интуитивно», на основе названия и, возможно, краткого описания. Детальному изучению будут подвергаться только несколько выбранных моделей или систем. Потому с точки зрения маркетинга разработчикам также важно донести максимум полезной информации уже в названии продукты. И здесь также используется IT-терминология.

Почему важна терминология для заказчиков?

Покупатель (заказчик) программного продукта должен четко понимать, чего стоит ожидать от выбранной системы и для чего она предназначена. Ошибочное понимание терминологии очень часто приводит к завышенным или просто неверным ожиданиям. Результат – разочарование, часто – необходимость дополнительных вложений средств и времени на необходимые доработки, а в самом печальном случае – продукт «в коробке» лежит невостребованный, а используется совсем другая программа.

Примеры ошибочного понимания основных терминов

ERP-система предназначена, прежде всего, для управления бизнес-процессами и повышения эффективности работы компании за счет построения и внедрения определенной бизнес-модели.

Часто под ERP руководители компаний понимают совсем иное. Для них это просто – «система все в одном». В результате они ждут, что ERP сможет полноценно заменить все другие программные продукты, не понимают, зачем нужны сложности с бизнес-процессами и почему далеко не всегда ERP подходит, например, для полноценной работы бухгалтерии или производства. Также недоумение вызывает необходимость сложного и длительного внедрения ERP-системы, интеграции с какими-то другими продуктами, полноценно заменить которые ERP не способна просто потому, что система предназначена для других целей.

Еще больше проблем и вопросов вызывает CRM-система, если руководитель не до конца понимает, что это такое, и как с ней правильно работать. Часто, начитавшись рекламных материалов, бизнесмены приходят к выводу, что CRM – это просто, покупают готовое решение и требуют от сотрудников, чтобы они начинали работать в новой программе. А когда оказывается, что CRM-система также нуждается в профессиональном внедрении, что часто программный продукт нужно не только настроить, но и доработать какие-то функции, приходит разочарование и ощущение обмана. Как итог, компания отказывается от вложения средств в настройку CRM-системы, работает «по старинке» и теряет на этом каждый день неполученную прибыль.

Что важно учитывать при анализе той или иной системы?

  1. Общепринятые сведения о системах выбранного типа. Основы терминологии, значение основных терминов, которые применяются при описании системы.
  2. Соответствие программного продукта термину, которым ее описывает разработчик. Например, отдельные «бесплатные CRM-системы» на проверку оказываются скорее планировщиками задач с возможностью совместной работы нескольких людей, к CRM это не имеет никакого отношения. Также часто системы, в которых имеются небольшие вспомогательные модули CRM или планировщиков задач позиционируют себя как «в том числе CRM-система» или «в том числе task-менеджер». На самом деле ограниченные возможности этих модулей не позволяют называть эти программные продукты ни тем, ни другим.
  3. Соответствие возможностей решения вашим требованиям.  Если вам требуется ERP-система, не имеет смысла покупать CRM и пытаться доработать программный продукт до возможностей ERP. Аналогично из task-менеджера делать CRM нецелесообразно. Доработок должно быть минимальное количество. И они должны применяться для адаптации наиболее подходящего под ваши требования программного продукта вашим специфическим требованиям, связанным с особенностями бизнеса.

Резюме: чем важны термины?

Главная причина изучения IT терминологии для покупателей программного обеспечения – это возможность заранее, до детального изучения или покупки понять, насколько система соответствует тому, что вам необходимо.

IT-терминология стандартна, профессиональные разработчики пользуются ей всегда корректно и грамотно. И даже в тех случаях, когда для маркетинговых целей применяются фразы, не совсем соответствующие действительности, например, «система объединяет в себе task-менеджер и CRM», при внимательном прочтении описания вы сумеете понять, что же имели в виду составители слогана на самом деле и что ждать от программного продукта.

В случае проблем с пониманием терминологии, вы либо выберете систему, вообще не подходящую для ваших целей (ошибочное понимание терминов), либо быстро запутаетесь в описании программного продукта и будете ориентироваться исключительно на рекламные слоганы.  А потому очень важно понимать, что вы хотите, как это называется правильно, и какие параметры системы (с правильными названиями) вам нужны. На самом деле, разобраться в минимальном количестве терминов совсем не сложно, а времени, сил и средств это экономит – очень много.

Об авторе
authorКинзябулатов Рамиль

Кинзябулатов Рамиль Хибатуллович, бизнес консультант и it консультант. Опыт автоматизации более 17 лет. Занимаюсь управленческим консультированием и разработкой it решений в составе команды Trinion. Автор 3-х книг и множества статей на тему организации труда.

Комментарии