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

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

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

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

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

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

Что такое API

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

Мы будем рассматривать этот вопрос с точки зрения пользователя, поэтому данная статья будет интересна именно пользователям и для начинающих программистов, которые хотят рассказать про API пользователю.

Проблематика.

Когда обыкновенный пользователь работает в одной системе, к примеру, оператор ЭВМ или оператор 1С, он вводит в учетную систему товары один раз. Если нужно внести те же самые товары, то вносит кто-то другой. Либо же он одновременно водит описание этого же товара на сайт для того, чтобы товар появился и на сайте, и в учётной системе. Чтобы можно было с одной стороны его продавать, учитывать в учетной системе, а с другой стороны, чтобы можно было его использовать для предоставления постоянной информации о товаре для посетителей сайта. 

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

Почему так происходит? Потому что мы ввели данные, для примера, в одну систему, но забыли ввести во вторую систему. То есть завели в учётную систему, а забыли на сайт. Или ввели в учетную систему по-одному, а на сайт по-другому. Соответственно, возникает вопрос контроля за двойным вводом данных. Для того чтобы его избежать, как раз-таки и был придуман обмен данными, и в частном случае — обмен данными по API.  

Итак, для начала разберемся, что такое API.

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

Первый шаг. Мы добавляем на сайт механизм API. Таким образом пользователь теперь вводит данные только в учетную систему.  

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

Теперь давайте рассмотрим плюсы системы API.

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

Теперь давайте рассмотрим, как это происходит, и какой в этом всё-таки есть минус. А минусы в данном случае есть.  

Как это происходит.

Механизм API основан на двух вещах. Это передача данных из системы «А» в систему «Б», назовем это так. Данные передаются в виде следующего набора: первое — это адрес, второе — непосредственно данные. То есть, если сравнить это с доставкой посылки по адресу, то, когда мы относим на почту посылку, мы пишем на посылке адрес, а внутрь кладем то, что мы непосредственно хотим отправить человеку.   

Адресом в нашем случае, будет являться тот адрес, который прописан в API. Например, добавить товар будет выглядеть так: https://www.trinion.org/addproduсt? Это будет адрес. Когда мы указали адрес, мы должны указать, что мы туда положили. Для примера, мы хотим название. Значит мы в API укажем, что за название у нас будет отвечать параметр «name». И вот, к примеру, мы в конце добавляем: «name = стул прикроватный».

Соответственно, что будет происходить после. Давайте посчитаем полную цепочку.   

1. Пользователь вводит в учетную систему данные с названием «стул прикроватный».  

2. Система сохраняет в себе эти данные.  

3. Затем она передает эти данные по адресу https://www.trinion.org/addproduсt?name=стул прикроватный.  

4. И система, и сайт создает у себя товар с таким же названием.  

Всё достаточно просто.  

Какой же минус есть в данной цепочке?

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

К примеру, если у нас в API написан механизм, что у нас «name» отвечает за название, а мы название в своей системе на сайте поменяли, и теперь вместо названия у нас будет название полное, то API не найдёт и не сможет создать этот товар. То есть это в некотором роде усложняет действия. 

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

Спасибо! 

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

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

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

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

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

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

‍