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

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

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

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

Варианты проектов внедрения

Можно выделить следующие причины организации проектов внедрения:

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

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

Сложность бизнеса растет

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

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

Пример. Оптовая компания увеличивает количество складов

Предположим, что информационная система обеспечивает ИТ-поддержку всей цепочки функций процесса — от приема заказов менеджером до отгрузки товара со склада. Было арендовано еще одно складское помещение.

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

Решено разные виды товара закрепить за разными физическими складами, а в системе сохранить единственный (логический) склад. Задания для складов создаются делением заказов по видам товаров.

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

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

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

Часто результатам внедрения можно дать количественную оценку, однако ее следует воспринимать с учетом бизнес-требований к организации процесса, в противном случае возрастает возможность их неверной интерпретации. Например, если на обслуживание клиента по определенной операции тратится 15 мин., из которых 10 мин. занимает построение специального отчета в информационной системе, то сокращение этого времени до трех минут даст почти двукратное улучшение обслуживания клиента (с 15 до 8 мин.). Дальнейшее уменьшение времени создания отчета уже не принесет особой выгоды с точки зрения бизнеса (в пределе можно достичь 5 мин.), если оно не будет сопровождаться изменением технологии обслуживания в целом.

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

Открывается новый сегмент бизнеса

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

Пример. Сопутствующие услуги при розничной продаже

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

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

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

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

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

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

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

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

Количественный рост

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

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

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

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

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

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

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

Кроме того

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

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

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