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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Все статьи: