пользователям программных продуктов Scala 5.1, iScala 2.1, iScala 2.2, iScala 2.3, iScala 3.0, iScala 3.1, iScala 3.2, iScala 3.3 (и так далее)

«Путь в тупик» или «Так ли дёшева самописная интегрированная система управления предприятием?»

Доклад на втором Российском Съезде ИТ-директоров в Санкт-Петербурге 03.06.2008, панельная дискуссия «Старое и новое — эволюция ИТ-систем в компании»

Здесь мне хотелось бы познакомить Вас с моим докладом на втором Российском Съезде ИТ-директоров. Я решил не публиковать презентацию, а разместить не только слайды, но и текст моего выступления.

В 2001 году я написал несколько популярных статей, первая из которых называлась примерно так: «Что лучше: заказная система или универсальная?»
Тогда речь шла лишь об учётных системах, сейчас, спустя 7 лет, я решил вернуться к старой теме, однако, уже применительно к ERP системам или, в более общем плане, к интегрированным системам управления предприятием (ИСУП).
О моём взгляде на этот вопрос, его связи с менеджментом и некоторыми тенденциями в этой области я и попытаюсь кратко рассказать. Кроме этого, я также попытаюсь привести свою собственную классификацию систем, этакий взгляд на них с точки зрения настройки, поддержки, модернизации.
Постараюсь не произносить названия конкретных программных продуктов и конкретных организаций, чтобы, во-первых это не было расценено как реклама или, упаси Господь, как антиреклама, а во-вторых, просто хотелось бы говорить не о достоинствах конкретного продукта или внедрения, но о некоторых тенденциях.
Итак, начнём:
В 1991 году мы с женой жили в маленькой комнате 8.85 кв.м. и для того, чтобы «вписать» в это пространство всё необходимое, я сделал собственными руками стеллаж-шкаф с откидным обеденным столиком со съёмной ножкой на шпильках, как в театре, ведь я умел делать театральные декорации, и собранная конструкция не показалась мне сложной. Тогда в 80~90-е годы многие вынуждены были всё делать своими руками, некоторые даже пытались собрать собственными руками автомобиль. Не догадываетесь, к чему это я?

Цитата: «Допустим, Вы решили обзавестись «Мерседесом». Вам не приходила [в голову] мысль - собрать несколько умельцев и «изваять» «Мерседес» где-нибудь во дворе вашего офиса? Самим сварить нужную сталь? Просверлить, отфрезеровать? Нет?» Из статьи «Двадцать один вопрос о корпоративных информационных системах» Владимир Баранов ООО «Интерконсалтинг»

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

Что купить? Классификация по типу построения функциональности: Системы с широкой базовой функциональностью; Системы «конструкторы» с ограниченной базовой функциональностью, но возможностью создания пользовательских функций. Классификация по типу настройки: Параметрически настраиваемые; Программируемые; Смешанные (параметрически настраиваемые со встроенным макро языком)

За время знакомства с различными информационными системами по управлению предприятия мне довелось видеть множество различных классификаций, например, по сложности и масштабу задач: Локальные, Финансово-управленческие, Средние интегрированные, Крупные интегрированные, однако, я попытаюсь взглянуть на них с иной точки зрения, которая ранее мне не попадалась на глаза: По типу построения функциональности и по типу настройки.
Сначала первое: Системы с широкой базовой функциональностью, где имеется огромное количество функций, часто организованных по модульному принципу. Здесь как бы заранее всё уже есть, на все случаи жизни, осталось разобраться, какая именно функциональность подходит именно вам и как её использовать. Системы «конструкторы», напротив, имеют ограниченную базовую функциональность, которая позволяет без изменений организовать управление лишь несложными процессами, любые иные потребности требуют создания дополнительных пользовательских функций. Подробнее на этом останавливаться не буду из-за отсутствия времени, думаю, вы сами можете привести пару-тройку примеров одного и другого типа систем.
Теперь – к типам настройки: Параметрически настраиваемые – системы настраиваемые с помощью параметров. Эти параметры могут быть «Глобальными» или относиться к одному отдельно взятому филиалу и/или отдельному финансовому году. Параметры могут быть независимыми или взаимозависимыми, когда действие одного параметра может менять действие другого параметра. Количество этих параметров в зависимости от используемой функциональности может измеряться сотнями и даже тысячами, а их настройка должна выполняться самыми опытными сотрудниками и/или консультантами по внедрению системы, простой пользователь не должен уметь это делать. О том, что даёт такой подход, чуть позднее.
В противоположность первым, программируемые системы подстраиваются под требования бизнеса не посредством правильного ответа на вопрос-параметр, а «дописыванием» программного кода
Со смешанными, по-моему всё ясно
Теперь чуть подробнее о параметрически настраиваемых системах:

Тип настройки системы: Параметрически настраиваемая. Плюсы: Универсальность: Наличие поддержки со стороны поставщика программного продукта, возможность пользования услугами службы поддержки «Горячая линия», масштабируемость, лёгкость обновлений версий, небольшое время, которое должен затратить «внешний» консультант, чтобы разобраться, как именно должна работать Ваша система. Минусы: Недостаток гибкости: Если нельзя сделать «в лоб», приходится придумывать обходные пути. Из-за необходимости системы при работе проверять большое количество параметров, быстродействие может быть ниже, чем у «программируемой» системы. Примечания: На мой взгляд, плюсы такого подхода намного существеннее минусов

Что даёт такой подход? А даёт он очень важную вещь: Универсальность. Настроив систему под свои нужды с помощью набора параметров, Вы можете быть уверены в том, что, обратившись по телефону к консультанту «Горячей линии», он должен Вам помочь. А установка новой версии параметрически настраиваемой системы не приводит к необходимости полностью переписывать всё то, что было «нажито непосильным трудом» (программистов).
Разумеется, всегда имеется и оборотная сторона медали: меньшая гибкость

Тип настройки системы: Программируемая: Плюсы: Гибкость: Как правило, можно добиться ответа «на любой чих». Из-за отсутствия необходимости проверять большое количество параметров, можно добиться большего быстродействия. Минусы: Уникальность системы: Отсутствие поддержки со стороны производителя продукта, полная зависимость от программиста, который дорабатывал систему. Фактическая невозможность перехода на новую версию системы. Примечания: Уникальность системы вопреки распространенному мнению - не плюс, а колоссальный минус!!! Минусы подхода настолько существенны, что достоинства ставятся под большое сомнение! Тип настройки системы: Смешанная (Параметрически настраиваемая система со встроенным макроязыком): Имеет плюсы и минусы, присущие соответствующим возможностям, описанным выше

При «дописывании» программного кода достигается бОльшая гибкость, однако, теряется универсальность. Если Вы много «дописываете», Вы тем самым создаёте уникальную, доработанную под Ваши нужды версию системы, которая отличается от исходной версии, поддерживаемой компанией разработчиком и службой «Горячая линия». Если теперь Вы захотите перейти на более свежую версию системы, Вам придётся повторить в ней все изменения, которые Вы вносили в Вашу версию. Задача, прямо скажем, нетривиальная, особенно с учётом того, что в новой версии исходная функциональность, которую Вы модифицировали, могла также претерпеть изменение.
Что касается смешанных систем, то именно о них следует говорить, ибо чисто параметрически настраиваемых, без возможности дописывания кода уже не осталось, вопрос лишь в том, потребуется ли вам использовать эту возможность или нет.

Примерный диалог клиента «доработанной» системы с консультантом «Горячей линии»: - Здравствуйте, у нас проблема с вашей системой; - Не с нашей, а с вашей. У вас стандартная конфигурация?; - Нет, конечно, мы слегка доработали её «под себя»; - Так обратитесь к тому, кто её дорабатывал!!!; - У нас был программист, но он уволился…; - Извините, ничем не можем вам помочь. До свидания!; - ???!!!

Лично я придерживаюсь консервативного подхода: делать изменения не тогда, когда можно, а только когда нельзя их не сделать. Рассматривать различные варианты, тщательно взвешивать, оценивать, что даст вариант и от чего я отказываюсь, выбрав его. Увы, часто вижу противоположный подход: «А можно ли использовать нашу систему как OLE Object?» Или «в какие таблицы БД я должен записать заказы на продажу? Щас мы всё быстренько тут перепишем». Приведенные вопросы, на мой взгляд, говорят о неопытности вопрошающего. Неужели он думает, что сможет «сваять» двигатель от Мерседеса «на коленке»? А даже если и сможет, что получится? Получится диалог, приведенный на этом слайде.

Построение ИСУП на базе программы «конструктора» или «Сколько стоит сделать «Мерседес» из новенькой «Оки»?»: Компания-разработчик системы с широкой базовой функциональностью - Опыт: Десятки лет * сотни программистов, тестеров, консультантов = миллионы человеко-часов. Поддержка и возможность решить проблему: Большой штат разработчиков, сотрудников службы поддержки, консультантов. Маловероятно, что известная компания в одночасье исчезнет с рынка. Собственный программист: Опыт - ?????? Поддержка и возможность решить проблему: Программист может уволиться, заболеть, уйти в отпуск. При «незаменимости» программиста, он может постоянно требовать повышения зарплаты и т.д., и т.п. А пользователи, вовлечённые в процесс?А как на счёт уверенности, что через 2 года не окажется, что очередное изменение невозможно, так как изначально заложенная структура просто не позволяет это сделать? И так далее, и тому подобное… И, наконец, действительно ли это дешевле?

Однако, пора задаться таким немаловажным вопросом, как стоимость того или иного варианта решения. При поверхностном взгляде покажется, что нанять собственного работника, который «напишет всё с нуля» на базе какого-нибудь известного коробочного решения с ограниченной базовой функциональностью, но со встроенным языком и набором готовых функций, гораздо дешевле, чем тратить деньги на недешёвую лицензию и последующее внедрение универсальной системы, большая часть функциональности которой адаптируется с помощью настройки параметров.
Так ли это на самом деле? Парадокс состоит в том, что только сейчас, пройдя несколько итераций сравнения обоих подходов, я понимаю, что это вовсе не обязательно так, а зачастую, совсем не так. И вопрос вовсе не в умении считать деньги, а в том, что последствия многих решений, связанных с информационными технологиями, становятся понятны лишь по прошествии времени, а кроме того, зависят от стадии жизненного цикла предприятия.
Обсуждая этот вопрос с коллегами «по цеху», я познакомился с наглядным подтверждением правильности своего предположения: Две похожих компании решили внедрить информационную систему. Первая компания внедрила некий универсальный продукт, что обошлось ей примерно в 3 млн. рублей. Другая — выбрала путь создания собственной системы «с нуля». «И что же?» — спросите Вы. А то, что цифры оказались теми же — примерно 3 млн. рублей.
А теперь зададимся вопросом «Что они получили за свои 3 миллиона?»
Первая — систему, которая поддерживается производителем и компанией, осуществлявшей внедрение. Масштабируемое решение, возможность перехода на новую версию, пользования услугами службы «Горячая линия».
Что «в сухом остатке» у второй компании? Уникальная, соответствующая требованиям текущего момента система, подстроенная под требования конкретного «чиха» конкретного сотрудника. Штатный программист готов и дальше реагировать на любой «чих», однако, если он, не дай Бог, пошел в отпуск или, что ещё страшнее, заявил, что уходит к конкурентам… Думаю, что Ваша собственная фантазия сумеет дорисовать картину. Скажу только, что меня уже не удивляют зарплаты в 100 тысяч чистыми плюс бонусы для таких «ценных сотрудников».

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

Немного о тенденциях и текущем моменте: - Стадия, когда большинство компаний пытались написать систему «с нуля», близка к завершению; - В то же время, наиболее вероятным сценарием выбора и внедрения ИСУП остается вариант системы «конструктора» с адаптацией системы под каждый «чих» конкретного пользователя (попытки сделать «Мерседес» из «Оки»); - Информационная зрелость большинства организаций и их руководителей остаётся очень низкой

Что же из этого следует? Как ни парадоксально, второй подход (под которым я понимаю не обязательно систему, написанную с нуля, но и достаточно сильно кастомизированную универсальную) в России многократно распространённее первого. Что, на мой взгляд, свидетельствует об управленческой незрелости, в общем, и о слабом понимании последствий такого решения, в частности. Моё личное мнение состоит в том, что действительно «уникальными», не «ложащимися» на функциональность универсальных ИСУП, являются бизнес процессы не более чем у 10% компаний, всё остальное — спекуляции, свидетельствующие об информационной и управленческой незрелости «спекулянта».

В чём причины? В том, что руководить процессом должен человек, являющийся профессионалом не только в IT, но и в менеджменте, но это пока ещё редкость; В том, что при выборе системы часто побеждает не тот, чья система лучше, а тот, кто обещает больше; В том, что при отсутствии воли руководства на первый план выходит удовлетворение потребности конкретных пользователей в «бантиках», а не сквозное движение информации; В том, что часто ИТ сотрудник и/или руководитель выбирает то, что интереснее ему в плане карьеры, то что делает его незаменимым, а не то, что требуется компании; В том, что так делают другие. И во многом другом, разумеется…

Для чего я это всё рассказываю? Я всего-навсего хочу, чтобы Вы задумались над вопросом: «От чего Вы отказываетесь, смещаясь от базовой функциональности к уникальной версии, допрограммированной под требования конкретных сотрудников Вашей организации?». Если Вы отчётливо понимаете это и осознанно выбираете такое решение, значит так тому и быть. На этой «оптимистической ноте» позвольте закончить…

Вопросов было задано не очень много, да и времени давалось всего 15 минут. Но, знаете, что самое интересное? В конце второго дня работы саммита подводились результаты голосования на лучший доклад по каждой панельной дискуссии. В нашей дискуссии признали лучшим выступление моего оппонента, что ещё раз подтверждает моё видение тенденции. Как говорится «это диагноз…»

Алексей Васильев. Ноябрь 2008 г.

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

Все статьи: