CC BY
163
№ 6(30) 2010
Е. С. Копцюх
Основные задачи этапа обследования в рамках проектов автоматизации
Перед началом большинства проектов автоматизации деятельности компаний так или иначе встает вопрос, каким образом правильно организовать процесс внедрения, чтобы обеспечить целостное видение будущей системы, снизить несогласованность в требованиях, выявить недочеты существующей системы управления и правильно распланировать проект, учитывая все риски.
Введение
Многие специалисты сходятся во мнении, что корпоративная информационная система (далее — КИС) не является панацеей от всех бед, гарантией успеха в бизнесе. КИС — это всего лишь инструмент для управления бизнесом и может использоваться руководством компании для воплощения представлений о том, какая информация, в каком виде и как часто нужна для принятия управленческих решений.
Для того чтобы этим инструментом воспользоваться, необходимо провести работы по построению информационной системы — проще говоря, внедрить КИС. Прежде чем перейти к реализации проекта автоматизации, руководству компании следует обратить внимание на стратегическую важность первоначальных этапов проекта внедрения — определить цели автоматизации, провести комплексное обследование компании и проработать стратегии дальнейшего внедрения.
Основные задачи этапа обследования
Допустим, клиентом принято решение о внедрении информационной системы и руководством сформулированы цели и задачи, которые будущая КИС должна реализовать. После этого возникает необходимость решить насущные вопросы информатизации: какие процессы компании автоматизи-
ровать, какой продукт внедрять, какие подразделения будут вовлечены в проект автоматизации? С точки зрения основ проектного менеджмента решения по этим вопросам немаловажно соотнести с доступными ресурсами предприятия — деньгами (бюджетом проекта) и временем (планированием внедрения во времени, управлением рабочего времени сотрудников).
Иногда (особенно это относится к крупным компаниям) руководству приходится задумываться над таким большим количеством вопросов (причем, решение некоторых проблем взаимосвязано), что в проекте возникает необходимость выделить отдельные этапы по обследованию существующих на предприятии процессов.
Если же компания мала и ее работа приближена к стандартам той или иной отрасли, то не нужно решать сложные стратегические вопросы. В этих случаях этап обследования оправданно можно пропускать или выполнять параллельно с другими работами (чаще — обучением).
Основные задачи, которые ставятся на этапе обследования:
• Описание бизнес-процессов компании с целью формулирования требований к КИС.
На этапе обследования обычно проходит подробное описание бизнес-процессов предприятия, которые необходимо автоматизировать. Происходит формирование модели существующего предприятия.
№ 6(30) 2010
• Анализ результатов обследования компании и выработка рекомендаций по их оптимизации.
Во время обследования определяется, что нужно изменить на предприятии в ходе автоматизации. Вряд ли в компании все идеально, и руководство захочет перенести то, «как есть», в создаваемую КИС. Если в бизнес-процессах предприятия присутствуют ошибки и нестыковки, которые вовремя не решаются, они могут быть перенесены в программный продукт.
• Определение стратегии реализации проекта.
Уточняются условия выполнения и ограничений проекта по внедрению КИС, принимаются решения по его планированию и реализации. Определяется стратегия развития КИС.
Описание бизнес-процессов предприятия
Началом работ считается сбор данных о деятельности компании. Консультантами проводится комплексное обследование всех процессов предприятия. Самым распространенным способом сбора необходимых данных являются опросы и анкетирование участников процессов, возможно, интервьюирование. В качестве источников данных в обязательном порядке используется регламентная документация компании:
а) разработанные стандарты;
б) регламенты;
в) положения организационной структуры;
г) система качества предприятия (если она есть).
Вся собранная информация структурируется и описывается в общепринятых форматах. Целью настоящей статьи не является исследование и сравнительный анализ подходов, позволяющих создавать модели бизнес-процессов предприятия. Но так или иначе использование любого из общепринятых подходов (функциональный, процессный и т.д.) гарантирует стандартизи-
рованное описание и понимание созданных моделей всеми участниками проекта.
Главной задачей будущей информационной системы в первую очередь становится решение проблем бизнеса посредством современных информационных технологий. Требования к программному обеспечению формируются на основе бизнес-модели, а критерии проектирования систем прежде всего основываются на наиболее полном их удовлетворении [7]. Для разработки КИС необходимо сначала построить модель деятельности предприятия — так называемую бизнес-модель — формализованное (графическое, табличное, текстовое, символьное) описание бизнес-процессов, отражающее реально существующую или предполагаемую деятельность компании. Построение такой модели — результат процесса бизнес-моделирования.
Хорошим вариантом использования термина «модель бизнес-процессов», раскрывающим его суть, является визуализация системы и деятельности компании. Очень важной функцией визуального моделирования считается помощь в осмыслении сложного предмета исследования. Абстрагирование от мелких и ненужных деталей и фокусирование на самых важных аспектах помогает человеку в анализе информации и принятии решения. Дело в том, что визуальное восприятие текста является сложным и не всегда оптимальным процессом, поэтому у человека оно работает на крайне небольшую мощность. Диаграммы же способны через тот же зрительный канал по-другому активировать умственную деятельность человека, и в сочетании с текстом они дают существенный выигрыш в донесении информации [4]. Как итог модель позволяет кратко, но полно зафиксировать результаты исследования, размышлений т.д. И эти результаты имеют гораздо больший коммуникативный потенциал — их можно обсуждать со специалистами различных профилей, что крайне важно при разработке КИС на заказ.
В ходе описания бизнес-процессы декомпозируются до отдельных функций в со-
№ 6(30) 2010
ответствии с необходимым уровнем детализации. В некоторых случаях важна градация функций по различным параметрам для удобной аналитики. Следует отметить, что собирается и структурируется не вся информация о предприятии, а только данные, которые затем смогут стать требованиями к будущей информационной системе (ИС).
Использование результатов. По итогам описания бизнес-процессов компании в соответствии с указанной методологией очень важным является формирование полных и исчерпывающих требований к автоматизации. Иными словами, необходимо произвести переход от бизнес-процессов и функций компании к четким и логичным требованиям к КИС. Нередко специалистами по информационным технологиям такой процесс называется формированием концепции ИС.
Создание структуры требований поможет снизить несогласованность в требованиях к системе (выявить пробелы и повторения, конфликты между требованиями), структурировать большой пласт информации с целью его осмысления, произвести дальнейшую оценку требований (по стоимости и времени) [2].
В ходе описания требований всегда стоит придерживаться баланса. С одной стороны, оно должно быть удобным для чтения, а его содержимое понятным «непрофессионалам» в области автоматизации. Хороший набор требований к управлению поможет обеспечить кратное и не слишком техническое описание того, что будет разработано, на уровне, доступном и разработчику, и клиенту.
С другой стороны, разработка требований к будущей информационной системе — это технический процесс. Программный продукт представляет собой совокупность четких алгоритмов, реализованных по законам логики и математики. Поэтому неточность в формулировках, несогласованность требований не допускаются. Только согласованные требования могут быть основой для дальнейшего планирования процесса
разработки системы [9]. Недостаточно проработанные и несогласованные требования часто определяют как «некачественные», т.е. не соответствующие целям и требованиям этапа. Возможные проблемы при формулировании требований:
а) неполнота;
б) плохая согласованность;
в) нерелевантность реальным запросам;
г) постоянное изменение требований.
Результаты обследования могут стать
базой для решения других задач (см. рис. 1).
Можно сказать, что правильно структурированные требования дают возможность уже на предварительном этапе обследования создать целостное видение будущей системы [1] и выявить недочеты существующей системы управления. Помимо функциональности, требования также являются базой для управления и планирования проекта и рисков, с ним связанных.
База знаний. Очень важно отметить, что требования к системе могут выступать в роли средства связи между проектами (вариантом реализации может быть некая «база знаний»). Инструменты такого рода помогают максимально увеличить использование наработок на разных проектах, накопленного опыта.
Л. Зеллс, консультант ¡БЭЮ, считает, что «в 9 случаях из 10 специалисты в области информационных систем работают над задачами, которые до этого ни они сами, ни кто-либо другой не выполняли. В отличие от каменщиков, десятилетиями кладущих одни и те же кирпичи одним и тем же способом, программисты не пишут одинакового кода». Это может быть правильным для определенных операций проекта, но все же важно делать шаги к структурированию сложно структурированного [3].
У многих 1Т-компаний, чья деятельность хорошо стандартизирована, уже имеются свои базы знаний, которые каждый раз пополняются при реализации следующего проекта. Структурирование такой информации
№ 6(30) 2010
Этап
«Обследование»
Реализация
Описание реализации
(в терминах информационного продукта)
Спецификация проекта
(описания, ориентированные на систему)
Определение требований
Анализ проблем бизнеса
Рис. 1. Работы по обследованию в рамках реализации требований к КИС
проходит по вполне логичному принципу — по программным продуктам, областям учета и подсистемам. Таким образом, повышается эффективность работы и обучаемость программистов и консультантов.
Психологические эффекты. Стоит отметить и другие положительные моменты, которое дает описание бизнес-процессов предприятия. Например, знакомство сотрудников компании-внедренца со спецификой работы заказчика. Каким бы большим ни был опыт консультантов, у любого бизнеса имеются особенности, которые нужно учитывать при автоматизации. Также не стоит преуменьшать и психологические эффекты от прямого контакта с клиентом. Возможно, после диалогов со специалистами компа-нии-внедренца некоторые сотрудники изменят отношение к будущему переходу на новую КИС, и на последующих этапах работать станет легче.
Правильная детализация дает возможность всем заинтересованным лицам увидеть реализуемость своих задач и стать сторонниками процесса изменений.
Анализ бизнес-процессов компании и выработка рекомендаций по их оптимизации
Как отмечалось ранее, правильно структурированные требования позволяют уже на предварительном этапе обследования провести их системный анализ с целью выявления недочетов существующей системы управления. В рамках реализации многих проектов по внедрению считается, что анализ бизнес-процессов, выработка рекомендаций по оптимизации и шаги по их изменению — это самостоятельный консалтинговый проект, который может длиться дольше, чем внедрение ЕРР-системы.
Если анализировать факт совместной работы по созданию ИС самой компании и сторонних внедренцев, то можно обнаружить, что компания-заказчик часто обращается к внедренцу именно как к консультанту, считая логичным, что предприятие с большим опытом реализации аналогичных проектов сможет более профессионально решить возникшие вопросы, не только связанные с функционалом будущей системы,
13
№ 6(30) 2010
но и с постановкой регламента и методологии учета.
В случае с большими проектами по автоматизации серьезной ошибкой является отказ от работ по анализу и оптимизации бизнес-процессов в рамках этапа обследования. Автоматизацию по принципу «как есть» проводить не следует, так как в результате обследования обычно обнаруживается масса нестыковок, бессмысленных работ, лишних затрат, противоречий в организационной структуре, устранение которых позволило бы уменьшить издержки и существенно сократить время исполнения различных бизнес-процессов [2]. Прежде чем приступать к внедрению системы автоматизации, в компании необходимо произвести частичную реорганизацию структуры и коррекцию бизнес-процессов. Кроме того, отсутствие формализованной системы управления снижает шансы на успешное внедрение КИС, поскольку хаос и неопределенность не поддаются автоматизации.
Неправильным было бы говорить, что сторонний консультант видит все проблемы заказчика и, читая ему нравоучения, переворачивает деятельность компании с ног на голову. Это не так, тогда необходимо исходить из привычного постулата экономической теории — экономический агент всегда поступает рационально и не во вред себе. Но руководству важно понимать, что то, как предприятие работало раньше, — результат ограничений существующей системы. Если дать более эффективные инструменты (учет информации, анализа и контроля процессов и т.д.), то выполнение тех или иных операций будет проводиться более логичным и рациональным способом.
Ожидаемым результатом на этом этапе обследования являются рекомендации по оптимизации (улучшению, нерадикальному реинжинирингу) бизнес-процессов компании, которые должны быть согласованы с руководством. Приняв эти рекомендации, компания может приступать к их реализации. После проведения обследования возможными вариантами развития событий мо-
гут стать приостановка проекта автоматизации или добавление дополнительных этапов с преобладанием консалтинговых услуг. Например, по мнению консультантов, предприятие «не созрело» для внедрения КИС, и выясняется, что для решения существующих проблем необходимо что-то качественно иное — перестройка системы управления или организационной структуры, а следующим этапом может быть построение информационной системы.
Такой результат обследования свидетельствует о том, что сторонний внедренец действительно хочет решить проблемы клиента, а не просто заработать деньги.
Определение стратегии развития КИС
После выполнения основных работ по обследованию деятельности компании следует решить важные вопросы по дальнейшей организации проекта. Помимо определения функциональности, требования пользователей к будущей системе также являются базой для управления и планирования проекта и рисков, с ним связанных. Отсутствие подробного и структурированного описания требований создает большие риски как для автоматизируемой компании, так и для внедренца. Не имея детальной структуры требований к автоматизации, внедренец может приступить к выполнению проекта, обрекая себя на постоянные изменения установленных рамок, пересмотр проектной документации. Это приводит к увеличению затрат при уже согласованном бюджете проекта.
Рассмотрим элементы дальнейшей схемы построения КИС на основе данных, полученных в результате обследования:
• Организационные рамки проекта — перечень подразделений и служб компании, охваченных проектом, чьи процессы будут автоматизированы.
• Функциональные рамки проекта определяются на основании функциональных требований, выявленных в процессе обсле-
№ 6(30) 2010
дования. Это могут быть не все выявленные требования. Некоторые бизнес-процессы действительно специально не автоматизируют с самого начала, отдавая приоритет более важным задачам. Примерами служат практические случаи, когда:
о не имея отлаженной системы учета фактических продаж, не совсем логично «закладывать» создание СРМ-функцио-нала;
о на предприятии не работает учет всех доходов и расходов, и тогда не стоит заниматься автоматизацией задач бюджетирования и финансового планирования.
Таким образом, по итогам анализа требований выявляются процессы компании, нуждающиеся в автоматизации, или определяются их приоритеты в рамках реализации всего проекта.
• Выбор средств автоматизации. Это очень сложный этап, особенности которого уже неоднократно были описаны в соответствующей литературе. Важный вопрос — какие программные продукты использовать: заказные системы или типовые и тиражируемые продукты. Плюсы и минусы таких вариантов общеизвестны. Но самое главное — у компании и приглашенного консультанта имеется вся необходимая информация, чтобы принять оптимальное решение. В любой момент можно проанализировать требования, изложенные в отчетах об обследовании, и сделать вывод, в какой степени хватит функционала типовых решений, каков примерный объем программирования нового функционала системы. Иными словами, подробные описания требований к автоматизации дают возможность произвести предварительную оценку реализуемости как в рамках типового решения, так и создания абсолютно новой КИС.
• Определение порядка реализации проекта. По завершении обследования выполняются разработка проекта по этапам/задачам, оценка его реализуемости с учетом ресурсных ограничений, планирование работ во времени. Этот этап обеспечивает органи-
зацию эффективного управления проектом, финансами компании и повышение темпов и качества выполнения проектов. Как видно из приведенного списка задач, на данном шаге часто используются инструменты проектного менеджмента, могут быть предприняты действия, направленные на уменьшение рисков клиента и разработчика, связанных с увеличением сроков и стоимости реализации проекта. Для идентификации риска, как правило, применяются методы качественной оценки случайных событий; количественный анализ риска возможно выполнить с помощью различных инструментов: моделей риска, а также по методам Монте-Карло или PERT.
Важным замечанием для документации взаимодействия клиента и заказчика является то, что выполнение работ на этапе обследования должно давать четкие и осязаемые результаты — согласованную документацию, схемы бизнес-процессов, стратегию дальнейших действий по проекту, концепцию внедрения. Некоторые исследователи считают этап обследования вспомогательным к основному процессу выполнения проекта, и поэтому результаты важны только для компании-внедренца, что неправильно. Итоги обследования не только повышают управляемость проекта руководством заказчика, но придают ему гибкость (наличие альтернативных вариантов), создают чувство независимости от компании-внедренца.
После обследования, имея на руках структурированное описание всей компании, зная выявленные проблемы и несогласованности, заказчик может:
• совместно с консультантами начинать выполнение основных этапов проекта по уже разработанной и согласованной последовательности дальнейших этапов, распределенных по времени;
• затормозить выполнение проекта и попытаться справиться с выявленными проблемами своими силами или с помощью консультантов (необязательно привлекать тех, кто проводил обследование);
№ 6(30) 2010
• возложить выполнение остальных этапов на другую компанию-внедренца. Это может быть не связано с плохим выполнением работ на этапе обследования. Возможно, вопрос заключается в компетенции внедренцев. Перед началом работ выделялись определенные области автоматизации. Но после обследования приоритеты поменялись, и первоочередной задачей стала автоматизация других областей, более сложных и обширных. На рынке есть примеры партнерства некоторых внедренцев. Если в ходе выполнения проекта выявляются задачи, требующие хороших компетенций в той или иной области, которых нет у внедренца, приглашают более сильную и опытную компанию-партнера;
• по результатам обследования распланировать последующие этапы с вероятностной оценкой работ. И логично, что требования компании-внедренца могут не удовлетворить заказчика. В итоге начнутся поиски компании, стоимость работ в которой будет укладываться в бюджет проекта автоматизации предприятия.
Во всех перечисленных случаях необходимым условием реализации данных стратегий является существование конкретных и осязаемых результатов обследования. Также при выполнении проекта хорошей практикой часто бывает налаженная обратная связь между его разработчиками и заказчиком с помощью периодических отчетов. В них должна содержаться информация об исполнении той или иной задачи и, что весьма существенно, объяснение, почему какая-либо из задач не была исполнена в срок. Эта информация ключевая для накопления статистики о производительности сотрудников и точности выдаваемых ими оценок, а иногда свидетельствует о проблемах самого руководителя проекта.
Заключение
При инициировании проекта по внедрению новой информационной системы со-
вместно со сторонней компанией-внедрен-цем заказчикам не стоит строить иллюзии о том, что все работы будут выполнены четко и быстро, с минимальным вовлечением в процесс своих сотрудников. Заказчику так или иначе придется вникать в суть терминов КИС, разбираться в тонкостях, нестыковках и проблемах, если он хочет их устранить и получить максимальный эффект от внедрения — избавление от двойного ввода одних и тех же данных, перевод процессов с бумаги в электронный вид, оптимизация (устранение «мусорных» процессов, проблем в бизнес-процессах). Получается, что ставится задача сделать не «как сейчас», «только перевести все в программу», а так, как того требуют современные методологии построения КИС. Перемены неизбежны, и с этим необходимо разбираться не только консультантам, но и руководству самого заказчика.
Прежде чем начинать автоматизацию деятельности компании, ее процессы нужно описать, формализовать и устранить их противоречивость. Описание бизнес-процессов — сложная и ключевая часть проекта. Лучше всего формализовать и описать процессы с помощью специалиста, имеющего опыт в данном вопросе, поскольку описание бизнес-процессов — основа для разработчиков ЕРР-системы, это схемы, согласно которым работает ваш бизнес. Они должны однозначно показывать кто, когда и что делает в компании. Любой программный продукт— синтез логики и математики, поэтому двоякого толкования ситуаций и процессов здесь быть не может.
В этом контексте важно, что одним из значимых этапов проекта внедрения является полное и достоверное обследование компании во всех аспектах ее деятельности. На основе заключения, полученного в результате обследования, возможно реализовать всю дальнейшую схему построения КИС.
Если в рамках внедрения информационной системы провести этап обследования, то можно выделить ряд экономических эф-
№ 6(30) 2010
фектов, которые получат обе стороны (заказчик и партнер-консультант). Следует отметить, что анализ итоговых эффектов от внедрения самой информационной системы будет ошибкой. В данном случае нужно опираться именно на результаты самого этапа обследования (достигаемые результаты, сгруппированные по задачам обследования). Далее приводятся обязательные результаты этого этапа и получаемые экономические эффекты:
1. Описание бизнес-процессов, подлежащих автоматизации, в форме, понятной не только консультантам, но и заказчику. Оно должно привести к формированию полных и исчерпывающих требований к автоматизации, а значит к более качественной автоматизации существующих процессов компании — установлению функциональных рамок проекта. Также стоит отметить такие инструменты, как базы данных, которые помогают максимально увеличить использование наработок на разных проектах, и накопленный опыт. Это ведет к снижению времени и затрат на последующие аналогичные проекты автоматизации.
2. Рекомендации по изменению бизнес-процессов (вырабатываются совместно с руководителем предприятия), способствующие устранению бессмысленных работ, уменьшению неоправданных затрат, противоречий в организационной структуре, избавление от которых позволило бы существенно сократить издержки и время исполнения различных бизнес-процессов.
Возможным вариантом развития событий может быть добавление в проект дополнительных этапов с преобладанием консалтинговых услуг. Их цель — усовершенствование процессов компании, в том числе и для более эффективной автоматизации. Безусловно, это снижает риски проекта по внедрению в целом.
3. Сформированная стратегия внедрения будущей системы, подробный план и бюджет проекта, что является крайне важным для целей планирования — все
стороны должны представлять, за что, когда и сколько должен платить заказчик. Сформированные планы, стратегии реагирования позволяют снижать риски как для автоматизируемой компании, так и для внедренца, исключают потенциальное увеличение затрат при уже согласованном бюджете проекта. Определение порядка реализации проекта обеспечивает организацию его эффективного управления в будущем.
Описок литературы
1. Апешкин С. А. Методы повышения эффективности внедрения корпоративных информационных систем. [Электронный ресурс]. http://www.iteam. ru/publications/it/section_53/article_1869/.
2. Баранов В. Двадцать один вопрос о корпоративных информационных системах. [Электронный ресурс], http://www.iteam.ru/publications/it/ section_52/articie_2210/.
3. Гавердовский А. Нельзя автоматизировать хаос. [Электронный ресурс]. http://www.hr-portal. ru/articie/neizya-avtomatizirovat-khaos.
4. Казанцев А. К., Должиков В. В. Математические модели и информационные технологии в менеджменте. Вып. 2. Сб. статей. СПб.: Изд-во С.-Петербургского государственного ун-та, 2004. — 224 с.
5. Каменнова М., ГэомовА., Ферапонтов М., Шма-талюкА. Моделирование бизнеса. Методология ARIS. М.: Весть-МетаТехнология, 2001. — 333 с.
6. Ильин В. В. Моделирование бизнес-процессов. Практический опыт разработчика. М.: ООО «И. Д. Вильяме», 2006. — 176 с.
7. Репин В. В., Елиферов В. Г. Процессный подход к управлению. Моделирование бизнес-процессов. М.: РИА «Стандарты и качество», 2004.
8. ERP Implementation life cycle. [Электронный ресурс]. http://www.slideshare.net/apurvgourav/erp-implementation-life-cycle.
9. Nick Mutt. Technical and Functional Consultant Requirements For ERP Implementation. [Электронный ресурс]. http://ezinearticles.com/7Technical-and-Functional-Consultant-Requirements-For-ERP-lmplementation&id=4247 687.
