Результативность автоматизации — различия между версиями

Версия 21:40, 16 мая 2014

Максим Цепков

главный архитектор компании CustIS (Заказные ИнформСистемы)

Журнал Директор информационной службы (CIO.RU), № 7, 15 июля 2009, стр. 40-42.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример: Пополнение со склада товарных запасов розничных магазинов торговой сети

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример: Интернет-магазин в оптовой компании

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

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

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

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

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

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

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

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

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

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

Пример: Печать накладных при отгрузке товара на складе

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

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

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

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

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

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

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

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

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

Кроме того

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

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