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

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

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

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

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

Рассмотрим каждый из этих шагов подробно и с примерами.

Оценивать бизнес-модели, а не функционал

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

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

Оценка системы на основе функционала приводит к ошибочному решению. Почему же она так распространена?

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

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

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

Мы считаем, что бизнес-процессы любой компании специфичны е, поэтому их анализ и соотнесение с новой информационной системой так важен.

Получение бизнес-модели системы

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

Первая причина отсутствия описания бизнес-модели - его большая сложность.

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

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

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

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

Что входит в описание бизнес-модели

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

  1. Перечень бизнес-процессов, автоматизируемых системой, и их описание в UML или любой другой широко распространенной нотации.
  2. Перечень основных справочников и документов системы. .
  3. Соответствие между документами и бизнес-процессами системы.
  4. Перечень ролей пользователей системы и выполняемых ими бизнес-операций.

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

Получение бизнес-модели по публичным материалам

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

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

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

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

Получение бизнес-модели от поставщика

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

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

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

Оценка бизнес-процессов компании в системе

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

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

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

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

В результате оценки все бизнес-процессы разбиваются по трем категориям:

1)      процесс адекватно поддерживается системой - их изменять нет необходимости;
2)      потребуется адаптация бизнес-процесса без ухудшения его результата;
3)      процесс не «укладывается» в систему; в этом случае придется мириться с сокращением бизнес-функций, или выполнять их вне системы (от чего заведомо пострадает результат), или существенно дорабатывать саму систему.

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

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

План изменения бизнес-процессов

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

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

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

Далее приведено несколько примеров решения подобных задач, позволяющих компании приспособиться к системе.

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

Решение. Для кассира конфигурируется специальное рабочее место, чтобы он видел активные заказы. При получении оплаты наличными кассир сравнивает ее с суммой заказа и ставит пометку о разрешении отгрузки в электронной и бумажной копиях документа. Это означает дополнительные операции для кассира (изменение бизнес-процесса), однако позволяет сохранить необходимый уровень контроля и не требует от клиента после внесения оплаты дополнительно обращаться к своему менеджеру за разрешением отгрузки.

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

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

Пример. Компания осуществляет продажу компьютеров с предварительной комплектацией. Как правило, заказы принимаются с учетом присутствующих на складе комплектующих. Однако в ожидании скорой поставки или от крупных клиентов заказ может быть принят и на отсутствующие детали. Задача состоит в том, чтобы при поступлении на склад соответствующие комплектующие сразу были зарезервированы за таким заказом. Резервирование в конкретной поставке использовать нецелесообразно из-за большой взаимозаменяемости комплектующих.

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

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

***

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

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

 

Максим Цепков - главный архитектор компании «Заказные ИнформСистемы» (CustIS); M_Tsepkov@custis.ru