Внедрение информационных систем, этапы, цели

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

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

С чего начинать внедрение информационной системы?

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

• Заключение контракта с крупной компанией, внедряющей ИС. К преимуществам можно отнести опыт компании-аутсорсера и отдельных ее специалистов, а также наличие собственных проектных наработок. К недостаткам относят стоимость работ, возможную текучку кадров и возможность того, что за громким именем могут стоять не самые лучшие специалисты;
• Приглашение небольшой, региональной IT-компании. Однозначным плюсом является высокая вероятность того, что внедрение автоматизированной информационной системы станет приоритетным проектом для нее. Если проект предстоит крупный, а значит долгий, стоит опасаться внезапных смен руководства, специалистов и приоритетов небольших фирм-внедренцев;
• Внедрение силами собственного IT-отдела. В этом варианте привлекает отсутствие дополнительных трат, постоянная связь со специалистами и возможность лично управлять проектом. Однако тут кроется и большая опасность – специалисты IT-отдела, зачастую зависящие от пользователей и руководства, полностью ориентируются их решения, в том числе не всегда правильные;
• Приглашение эксперта. Отличный способ сэкономить и получить специалиста в нужной области. К недостаткам можно отнести необходимость высокой организованности всех сотрудников компании, зависимость успеха от одного человека и формальную ответственность за проект.

Начало внедрения

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

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

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

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

Технология внедрения информационных систем

Бесплатная
консультация
эксперта

Наталия Сиворина

Консультант-аналитик 1С

Спасибо за Ваше обращение!

Специалист 1С свяжется с вами в течение 15 минут.

Этапы внедрения информационной системы

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

Если компания хочет не просто «для галочки» внедрить ИС, а действительно эффективно пользоваться всеми ее возможностями, предстоят следующие этапы:

1. В первую очередь необходимо определить цель внедрения. Многие руководители высшего звена поверхностно относятся к этому этапу, но на самом деле он задает направление всему внедрению ИС;
2. Обследование бизнес-процессов компании. В этот этап входят интервью с менеджментом, рядовыми сотрудниками, составление схем по каждому процессу. На выходе получается уточнение целей внедрения и возможность предварительно оценить объем работ и стоимость;
3. Составление проекта, технического задания и регламента. В этих документах должны быть описаны все бизнес-процессы, участвующие во внедрении ИС. Старайтесь составлять проект внедрения максимально подробно, с указанием необходимых данных, их структуры, алгоритмов действий, рабочих мест;
4. Подготовка специалистов. Сотрудники компании при начале внедрения должны знать, что от них требуется, чтобы не задерживать выполнение работы. Также администраторы и разработчики компании должны начать разбираться в информационной системе. То есть сотрудники расширяют свои знания на благо компании;
5. Настройка информационной системы в соответствии со спецификой предприятия. В этот этап включается:
   • Разграничение прав на функционал системы для сотрудников;
   • Начальное заполнение данных;
   • Настройка алгоритмов расчетов, создание необходимых отчетов.
6. Тестирование информационной системы. На этом этапе могут обнаружиться проблемы внедрения в разрезе алгоритмов или необходимость в новых отчетах;
7. Опытная эксплуатация с реальными данными. Чаще всего на этом этапе многие сотрудники компании выполняют больше работы. Им приходится не только работать, как раньше, но и отражать свои действия в информационной системе. Требуется максимальная дисциплина и сосредоточение усилий всех участников внедрения. Конечным результатом должно стать совпадение данных информационной системы с реальным положением дел;
8. Промышленная эксплуатация. На этом этапе осуществляется переход сотрудников на полноценную работу в информационной системе. Должна быть организована техническая поддержка пользователей;
9. Завершение проекта. Основным результатом этапа являются подписанные должностные инструкции, разграничение обязанностей подразделений и их взаимодействия. Корпоративная информационная система запущена на предприятии.

Этапы внедрения информационной системы

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

Организация процессов производства информационных систем. Часть 4. Внедрение информационной системы

IX Внедрение информационной системы

Нет ничего труднее, опаснее и неопределённее, чем руководить введением нового порядка вещей, потому что у каждого нововведения есть ярые враги, которым хорошо жилось по старому, и вялые сторонники, которые не уверены, смогут ли они жить по новому.
Н. Макиавелли

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

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

1. Развертывание системы на площадке опытной эксплуатации

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

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

Рисунок 19. – Пример технического описания этапа внедрения

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

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

Между тем 90% времени уже пролетело…

2. Обучение персонала заказчика работе с информационной системой

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

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

А мы на этапе проектирования предупреждали, что обучение персонала заказчика не только очень ответственная задача, но еще и очень трудоемкая…

3. Выявление недостатков и дефектов информационной системы

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

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

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

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

А тем временем мы достигли дна, отведенного для проекта времени…

4. Согласование изменений в процессе внедрения информационной системы

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

Этап согласования нового решения очень важен, как минимум по двум причинам.

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

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

И вот перефразируя Ежи Леца: «Когда мы достигли дна отведенного времени, снизу постучались …»

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

5. Доработка информационной системы по итогам опытной эксплуатации

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

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

Собственно говоря, наступил момент, когда актуальны следующие условия:

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

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

Рисунок 20. – Этап внедрения информационной системы

Без комментариев…

6. Передача информационной системы в промышленную эксплуатацию

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

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

7. Резюме раздела

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

1. Развертывание системы на площадке промышленной эксплуатации, включая поставку оборудования, установку системного ПО, установку актуального релиза внедряемой системы и т.п.;
2. Обучение пользователей работе с системой, включая администраторов, специалистов по обслуживанию оборудования и т.п.
3. Выявление и устранение недостатков и дефектов, выявленных в ходе опытной эксплуатации.
4. Согласование изменений в работе системы и приведение ее к соответствию контрактным обязательствам;
5. Подписание документов о выполнении договорных обязательств. Произведение полного расчета за выполненные работы;
6. Ввод системы в промышленную эксплуатацию;

Список литературы

1. Вольфсон Борис- «Гибкие методологии разработки»
2. Якобсон А., Буч Г., Рамбо Дж. – «Унифицированный процесс разработки ПО» (2004)
системы»

Эффективность внедрения информационных систем. Опыт практика / Habr

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

Первая и самая главная причина провала: некорректно поставленная цель для информационной системы.

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

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

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

Даже если предположить, что специалисты-информационщики знают, как следует изменить бизнес-процессы (с логикой у нас порядок), у них все равно нет нужного административного ресурса, да и ожидаемый результат зависит, в первую очередь, не от программного обеспечения. Здесь явно путается следствие и причина. Допустим, есть предприятие А с информационной системой ABC. Предприятие работает стабильно, нет авралов, неразберихи, заказы выполняются в срок, есть планомерная деятельность отлаженного механизма. Можно сделать вывод, что все хорошо благодаря системе ABC, но это 100% не так. Наличие системы ABC у предприятия A, кончено же, вносит свой вклад в бизнес, но не является ключевым. Если руководство некоего предприятия Б решило внедрить у себя систему ABC в надежде, что после ее внедрения предприятие Б тоже будет работать так же, как A, его ждет сюрприз. Деньги будут потрачены, но ожидаемый эффект не наступит, т.к. методика работы на предприятии Б не изменится.

Эффективные цели

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

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

Итак, с целями мы определились, теперь осталось правильно составить техническое задание.

Техническое задание

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

Получается, что не заказчик подписал неподходящее ТЗ, а исполнитель разработал и предложил совсем не то – не угадал, о чем мечтал заказчик. Замечаете парадокс? Исполнитель сам для себя пишет ТЗ, но при этом должен угадать, чего на самом деле хочет заказчик. В принципе, это возможно (для участников шоу «Битва Экстрасенсов»), но маловероятно. У меня был опыт создания подробных ТЗ, которые на этапе внедрения претерпевали изменения порядка 30%. Обычная история: в процессе работы над проектом у заказчика появлялись новые идеи, их приходилось учитывать, отказываясь от предыдущих решений. Потому я не сторонник очень подробных ТЗ. Они отнимают много времени, а в итоге будут скорректированы на этапе опытной эксплуатации и внедрения. Если не сделать корректировку, можно испортить отношения с заказчиком. При попытке сослаться на подробное ТЗ в ответ вы услышите – «ну, вы же специалисты, должны были сами все знать заранее».

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

Есть еще один вариант составления ТЗ: в нем декларируется конечная цель заказчика. И тут вы можете сразу заметить противоречия с предыдущем написанным тестом. Это случай составления проекта, в котором информационная система является только частью. У меня был опыт внедрения комплексной системы управления компаний, где основная сумма по контакту выплачивалась в случае, если заказчик получит увеличение оборота в два раза. Спрашивается, это как? Ответ прост: цели заказчика — автоматизация и оптимизация бизнес процессов копании, ускорение процесса работы с клиентами, точный учет затрат по контрактам, точный расчет бонусов менеджерам, участвующим в контрактах, финансовое планирование. Исходя из того, что все эти задачи не были решены, я подписал контракт. К сожалению, достигнуть 100% увеличения объема оборота у заказчика за 1 год не удалось, но 83% тоже хорошо. Мое вознаграждение было выплачено пропорционально.

Следующим важным документом для успешного выполнения работ является план-график работ.

План-график работ

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

Запуск системы в работу

Запуску системы предшествует тестирование исполнителем системы на примерах заказчика. После получения положительных результатов начинается работа по реальному внедрению и запуску системы. Если опытная эксплуатация делается только на опытных примерах без участия рядовых исполнителей заказчика, без использования реальных задач, она не достигнет поставленной цели. Целью же является сбор замечаний, которые необходимо устранить для перевода в промышленную эксплуатацию. Данный этап правильнее было бы назвать расширенным тестированием с привлечением исполнителей заказчика. Реальная опытная эксплуатация начинается после внедрения системы при участии, как минимум, 50-70% процентах рабочих мест.

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

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

В итоге мы получаем такие этапы запуска и внедрения системы:

• Тестирование с привлечением сотрудников заказчика на реальных примерах;
• Опытная эксплуатация с немедленным устраняем возникающих проблем;
• Промышленная эксплуатация.

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

План внедрения системы ERP: пошаговая инструкция

Вопросы, рассмотренные в материале:

• Что такое система ERP?
• В чем плюсы и минусы системы ERP?
• Из каких этапов состоит план внедрения системы ERP?

В современном обиходе не существует единого понятия «ERP-системы», поскольку данную аббревиатуру довольно часто используют для обозначения разных по своей сути интегрированных информационных структур. Дословно ERPS (Enterprise Resource Planning System) переводится как «система планирования ресурсов предприятия». Ее прямое предназначение заключается в автоматизации учета и управления корпоративными ресурсами организации. О том, как разработать грамотный план внедрения системы ERP, вы узнаете из нашей статьи.

Что такое система ERP

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

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

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

Результаты автоматизированного анализа способствовали более грамотному распределению производственных мощностей и последующему принятию оптимальных решений для развития бизнеса. Методику ведения бизнеса с применением различных автоматизированных программ управления ресурсами предприятия назвали ERP, а программное обеспечение, используемое в этих целях, – ERP-системой. То есть все компьютерные программы, предназначенные для работы бухгалтерии, управления персоналом и т. д., являются частями системы ERP, при этом CRM (customer relationship management system) тоже относится к ERP и переводится как «система управления взаимоотношениями с клиентами».

Стоит отметить, что система ERP стала результатом развития более простых концепций: MRP (Material Requirement Planning – планирование материальных потребностей) и MRP II (Manufacturing Resource Planning – планирование производственных ресурсов). Внедрение программного обеспечения систем ERP позволяет осуществлять производственное планирование, моделировать поток заказов и оценивать возможность их реализации в службах и подразделениях подчиненной организации.

Возможности большинства систем ERP позволяют охватить все основные направления деятельности предприятия.

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

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

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

Топ-3 статей, которые будут полезны каждому руководителю:

Плюсы и минусы системы ERP

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

Помимо этого среди преимуществ внедрения системы ERP следует выделить:

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

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

• Защиту данных. Администратор может категорировать всех пользователей системы ERP, предоставив каждой категории доступ к определенным ресурсам и функциям. Но при этом действия каждого пользователя можно будет легко отследить и проверить.
• Централизацию информации. Внедрение системы ERP позволяет хранить все данные организации в одном месте, благодаря чему в случае необходимости всегда можно будет получить нужные сведения.
• Интеграцию с другими системами. В случае применения API-интерфейса ERP-системы могут взаимодействовать с системами более низкого уровня, такими как технологическое оборудование, производственные комплексы и станки.
• Повышение эффективности взаимодействия. Внедрение системы ERP предусматривает наглядную демонстрацию результатов работы каждого подразделения, что помогает улучшить взаимодействие между ними.
• Масштабирование. Разработка и внедрение ERP-системы особенно актуальна для компаний, имеющих представительства в других регионах, поскольку ее модули позволяют наладить централизованное управление и масштабировать принимаемые решения.
• Обеспечение контроля в смежных направлениях. ERP-системы являются совокупностью программ с различным функционалом, что помогает контролировать все сферы деятельности компании: отслеживать статусы заказов, показатели материального обеспечения, финансовые потоки и другие параметры по основным направлениям работы предприятия.

Но, несмотря на все вышеперечисленные достоинства, систему ERP нельзя назвать совершенной, поскольку она имеет и некоторые отрицательные моменты:

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

Пошаговый план внедрения ERP-системы

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

1. Организационный этап.

С чего же начать внедрение ERP системы на предприятии? Введение ее должно начинаться с определения основных целей и задач. Не стоит проводить автоматизацию ради автоматизации – заказчик должен иметь четкое представление о желаемых результатах.

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

• Руководитель (его лучше выбирать среди топ-менеджеров организации). Он должен быть осведомлен обо всех бизнес-процессах, протекающих на предприятии. Помимо этого, у руководителя проекта внедрения системы ERP должны быть полномочия по единоличному принятию решений по любым вопросам.
• Специалисты, контролирующие соответствие внедряемой системы актуальным нормативно-правовым актам и корпоративным стандартам. Это могут быть: исполнительный директор, главный бухгалтер или начальник IT-службы.
• Начальники всех подразделений, которые в дальнейшем будут пользоваться новым программным обеспечением. Они должны будут консультировать специалистов по внедрению в ходе изучения последними бизнес-процессов предприятия, а также организовывать работу подчиненных сотрудников после завершения автоматизации.
• IT-специалист широкого профиля. Его основной задачей будет техническое сопровождение плана по внедрению системы ERP.

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

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

2. Этап обследования предприятия.

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

• Экспресс-обследование. Занимает от 1,5 до 2 месяцев. Результатом обследования является «Предпроектный анализ», в котором описываются все нюансы автоматизированного учета и перечень задач, подлежащих решению в ходе внедрения.
• Полное обследование. Длится на протяжении 3–5 месяцев. В результате тщательного обследования формируется «Техническое задание», готовятся бизнес-процессы автоматизированного учета, а также указывается перечень необходимых корректировок программного обеспечения.

Выбор конкретного плана обследования зависит в первую очередь от методологии внедрения ERP.

3. Выбор методологии внедрения ERP.

Существует четыре основных варианта внедрения ERP-решений на платформе «1С: Предприятие»:

• Абонентское time and material. IT-интегратором проводится экспресс-обследование организации, формируется план проекта внедрения ERP-системы и рассчитывается максимально возможная стоимость работ. Данная цифра прописывается в договоре, так же как и стоимость одного часа работы специалиста, интегрирующего программу.

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

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

Данная методология не предусматривает составления четких планов работ на неделю или месяц, перечень и очередность выполнения задач определяется актуальными потребностями организации. То есть главное достоинство технологии быстрого результата – в ее гибкости. Изменения вносятся в план внедрения системы ERP без длительных согласований. К числу минусов методологии относят отсутствие возможности определения точных сроков внедрения ПО.

4. Проектирование системы ERP.

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

5. Внедрение ERP-системы на предприятии.

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

6. Запуск системы в эксплуатацию.

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

7. Сопровождение внедренной системы.

Бесперебойная работа ERP-системы на платформе «1С: Предприятие» возможна при условии поддержки после внедрения.

Методика подхода к проекту внедрения информационной системы

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

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

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

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

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

Причины и предпосылки внедрения системы

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

Отсутствие информационной системы

Самая важная причина для построения/внедрения новой системы – это ее отсутствие. Эта причина может возникать как для новообразованных организаций, когда все строится «с нуля», так и для уже существующих компаний при расширении области своей деятельности, радикальном изменении какого-то из процессов. Например, торговая компания решает открыть собственное производство, для чего закупает новые станки.

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

Недостаток быстродействия имеющейся системы

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

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

Недостаточный уровень автоматизации процессов

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

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

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

Снятие системы с поддержки производителем

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

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

Несоответствие системы требованиям компании

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

Несовременность системы

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

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

Анализ необходимости и выбор решения

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

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

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

•    Обучение пользователей работе в новой системе.
•    Возможная потеря в производительности на некоторый период во время внедрения новой системы.
•    Затраты на внедрение/модернизацию системы. Оценка рентабельности.
•    Выделение собственных IT-ресурсов (или же поиск партнера-аутсорсера) для внедрения системы.
•    Возможность интеграции новой системы с другими имеющимися на предприятии системами.

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

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

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

•    Уровень соответствия имеющимся процессам.
•    Стоимость решения (включая стоимость необходимых модификаций и внедрения).
•    Защищенность информации в системе.
•    Сложность модификации (стоимость, трудозатраты, квалификация и наличие специалистов).
•    Стоимость дальнейшего содержания (сопровождения) системы.
•    Масштабируемость.
•    Универсальность/узконаправленность.
•    Удобство использования.
•    Требования к аппаратной части.
•    Возможность интеграции с другими решениями, открытость системы.
•    Возможность расширения функциональности системы и способ расширения.
•    Качество поддержки базового решения поставщиком.
•    Надежность поставщика/производителя базового решения.

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

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

•    Аппаратная часть – это серверы, компьютеры пользователей, устройства взаимодействия.
•    Платформа/СУБД, проще говоря, основной «движок» системы.
•    Клиентская часть, интерфейс пользователя и настройка СУБД, отражающий необходимую функциональность новой системы.

Выбор готового базового решения полностью определяет платформу и может частично или полностью соответствовать в области клиентской части, а так же задавать требования к аппаратной поддержке. В случае, когда готового решения нет, и требуется разработка собственной системы «с нуля», выбор основной СУБД позволяет определить требования к остальным компонентам ИС.

Контроль и принятие решений

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

•    Предпроектные работы.
•    Разработка, адаптация, подготовка прототипа системы.
•    Запуск системы.

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

Предпроектные работы

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

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

Разработка

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

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

Запуск

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

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

Необходимость принятия решений

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

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

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

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

Разработка и внедрение информационных систем на предприятии

Вопрос: «Кто осуществит внедрение информационной системы?», чрезвычайно важен в каждом из случаев запуска проекта автоматизации.

Данный тезис неоспорим, по нескольким причинам:

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

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

Внедрение информационных систем в основном происходит по одной из следующих схем:

1. Внедрение осуществляет компания-внедренец;

2. Собственный отдел информационных технологий;
3. Привлекается фрилансер, который выполняет функцию руководителя проекта.

            Рассмотрим каждый вариант подробнее.

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

Нюансы работы с крупной компанией внедренцем:

• Внедрение информационной системы поставлено на поток;

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

• Неудача на «небольших» проектах мало влияет на общую репутацию компании и отношения к таким проектам соответствующее;

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

• Стоимость услуг – самая высокая из всех рассматриваемых вариантов.

Альтернативный вариант – небольшая компания:

• Проект может стать приоритетной задачей для специалистов компании;

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

• Успех проекта полностью зависит от квалификации сотрудников компании и в первую очередь менеджера проекта;

• Обходятся значительно дешевле чем.        

Собственный отдел информационных технологий (ИТ).

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

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

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

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

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

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

Но никто не гарантирует, что данный специалист сможет стойко преодолевать менеджерские проблемы которые были описаны в предыдущем пункте.

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

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

Делая выводы из всего вышесказанного, хочется зафиксировать:

• Привлечение крупной компании внедренца – прерогатива крупных компаний, успех проекта с которыми будет иметь имиджевую составляющую для внедренца;
• Небольшая компания лучше подходит для не самых крупных внедрений, однако надо чутко следить за ходом внедрения информационной системы;
• Внедрение силами собственного ИТ подразделения, при данной схеме крайне высок риск перевода проектной деятельности в операционную, проект будет длится годами, а цели будут постоянно меняться;
• Фрилансер – интересный подход к реализации, но требует кропотливого подхода к выбору персоны консультанта. К сожалению, руководителям инициировавшим внедрение информационной системы трудно определить уровень компетентности ИТ специалиста, ввиду отсутствия опыта проектной деятельности в ИТ сфере. Кроме того, ключевым фактором данной схемы может быть уровень возлагаемых на специалиста компетенций.

Исходя из того, что предложенные способы не идеальны.

Внедрение программного продукта. Особенности работы бизнес-консультанта. Часть I

Труд — это отец удовольствия.

Стендаль.

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

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

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

Еще раз: главное – решить поставленную бизнес-задачу!

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

Вы внедряете такое программное обеспечение, которое будет:

• Эффективно решать те задачи, которые поставил перед вами клиент.
• Поможет вам найти решение проблем, которые возникли в бизнесе.
• А также, естественно,

будет решать все те задачи, которые решало старое программное обеспечение.

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

Например:

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

Вы знаете, что эту задачу можно эффективно решить, если внедрить 1С Управление торговлей 11. Более того, этот компонент будет также эффективно работать с теми задачами, которые решает текущий программный продукт. В результате вы предлагаете к внедрению 1С Управление торговлей 11. Но в плане работы вы описываете эти процессы как «Внедрение учета эквайринговых операций». Потому что именно решение этой задачи является вашей целью. Это должны постоянно помнить и вы, и ваш клиент.

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

1. Получили перечень задач, которые нужно реализовать.
2. Доработали программный продукт с учетом пожеланий клиента.
3. Установили везде программу, настроили.
4. Провели краткое обучение.
5. Оставили инструкцию, написанную техническим языком и понятную, чаще всего, только системному администратору.

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

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

Почему так происходит?

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

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

Свои бизнес-задачи разработчики, понятное дело, реализовали в полном объеме. А как компания будет работать далее при помощи их программного обеспечения, в большинстве случаев, им уже не интересно.

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

Что такое внедрение?

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

(Википедия)

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

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

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

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

Ошибки при внедрении.

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

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

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

Для того чтобы избежать перечисленных ошибок, вам обязательно нужно донести до клиента простую мысль:
Здесь и сейчас вы выполняете уникальную работу, в уникальном окружении с уникальным результатом. А потому точно спрогнозировать все нюансы – просто невозможно!

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

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

В зависимости от сложности и объема предстоящей работы я чаще всего называю какие-то примерные сроки. Это могут быть 2 – 4 месяца или от полугода до 1,5 лет. Да, я не знаю точных сроков реализации проекта, как и не могу заранее точно сказать, как именно будет выглядеть результат моей работы. Но я точно знаю самое главное – это основную цель, а также, как именно реализовать каждый этап работы.
Т.е. я использую тот самый принцип, о котором уже упоминал в связи с японской стрельбой из лука Юми: сосредоточьтесь на каждом действии, на каждом этапе, качественно выполняйте каждое действие. И тогда вы обязательно придете к цели!
С чего начинается внедрение?

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

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

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

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

Приведу пример. Когда-то я и сам слишком углублялся в технические нюансы и пытался пояснять чем, скажем, MailChimp отличается от 1С рассылки. Я рассказывал об API, о статистике, о числе отказов, а также о других технических параметрах. При этом клиенту, на самом деле, нужны были совсем другие данные. Ему было достаточно продемонстрировать пример письма и показать пример статистики, чтобы мы поняли друг друга и клиент понял выгоду для себя.

Говорите с клиентом с его точки зрения и на его языке!

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

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

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

О моем подходе к процессу внедрения я напишу в следующей статье.