Функциональный разрыв 1с что это

Назначение функционального моделирования

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

Выдержка из публикации профессора Н.Е. Жуковского «О парении птиц». 1891 г.

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

На выходе функциональное моделирование (ФМ) даёт приблизительный результат (точный даст — опытная эксплуатация):

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

Должен ли владелец бизнеса ответить на те же вопросы при запуске новой системы 1С:Предприятие (1С ERP, КА, УТ и др.) да и всего остального ? Однозначно. Функциональное моделирование как раз для этого и предназначено.

Предлагаю оглавление по документу ФМ:

• Описание бизнес-процессов предприятия (As is/To be).
• Выбор решений программного и аппаратного обеспечений.
• Насколько соответствует типовое решение техническим требованиям и бизнесу?
• Какая допустимая нагрузка на систему / подсистемы?
• Какие условия информационной безопасности?
• Обзор текущей инфраструктуры.
• Какие функциональные разрывы между системой и бизнес-процессами и способы их устранения?

As is/To be

Модель «To be» описывается всегда.

Модель «As is» описывается в случаях работающих (управляемых и осознанных) процессов предприятия, составления стратегии плавной реорганизации, для определения критериев эффективности новой архитектуры.

Типовое решение и функциональные разрывы

Вернёмся к математике, к формуле нормального распределения, график которого имеет следующий вид:

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

В ФМ требуется определить попадание бизнес-процессов в функциональность системы. Если количество редких бизнес-процессов велико, то требуется выбирать иное программное обеспечение (комплекс программ) или значительно дорабатывать существующее. Требуется компетенция аналитика, то есть знание продукта и отсутствие неловкости в вопросах «почему? и «зачем?».

Ниже представлен слайд отчёта фирмы 1С по программному продукту 1С ERP, который резюмирует, что «89% функционала внедряется без доработок или с небольшими доработками».

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

Нагрузочное тестирование

Фирма 1С разрабатывает и предоставляет внедренцам комплекс программ «1С:Корпоративный инструментальный пакет 8» для повышения успеха проектов, в том числе на этапе функционального моделирования.

Основные задачи «1С:Корпоративного инструментального пакета 8»:

• автоматизированное проведение многопользовательских нагрузок без участия пользователей;
• оценка применимости и масштабируемости системы в соответствии технических требований;
• выбор аппаратного(серверного) и программного обеспечения;
• расчёт показателей производительности системы во время ее нагрузочных испытаний или рабочей эксплуатации;
• информация по динамике производительности системы;
• поиск и «узких мест» и оптимизация кода системы;
• автоматизированное функциональное тестирование конфигураций.

Это больше чем необходимо на ФМ, но крайне важно на средних и крупных проектах (внедрения по технологиям ТБР и ТКВ). Для внедрения ТСВ (Технология стандартного внедрения) допускается не делать нагрузочное тестирование.

Документирование

Результатом функционального моделирования должен стать:

• одноимённый документ, в котором описаны бизнес-процессы, поведения системы, результаты тестирования и требуемые функциональные доработки,
• база(ы) данных.

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

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

Проводники в джунглях системной сложности

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

Системная сложность

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

1. Превосходство ключевых бизнес-процессов по отрасли — за счет новых технологий, за счет большей специализации, за счет новых маркетинговых идей. Именно этим определяется текущее (статическое) конкурентное преимущество организации: в важном она не такая, как все, и именно поэтому — лидер, именно поэтому эффективнее других! 2. Опережающую модернизацию ключевых бизнес-процессов. Прогресс не стоит на месте: технология, которая несколько лет назад была инновацией, отличительной чертой немногих, сегодня для большинства предприятий — стан­дарт де-факто. Чтобы не утратить лидирующее положение, необходимо периодически видоизменять ключевые бизнес-процессы. Для организации в целом это выливается в дискретно-непрерывное обновление своей деятельности. Умение совладать с процессом изменений и не потерять устойчивость — вот ее динамическое преимущество перед конкурентами. Попросту говоря, организация должна бежать вперед быстрее других.

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

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

Функциональный разрыв

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

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

Рис. 1. ИТ-проект в многомерном пространстве требований

Тут мы сталкиваемся с функциональным разрывом — раз­ни­цей между «целевым» функционалом, который нужен бизнесу, и функционалом «прототипа», который реализован в модуле (разрыв иллюстрируется расстоянием между точками).

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

Далее начинается длительный итеративный процесс ликвидации функционального разрыва. Это весьма непросто даже в том случае, если «цель» зафиксирована. И это очень сложный процесс, если понимание цели изменяется во времени.

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

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

Рис. 2. ИТ-проект в многомерном пространстве требований

Результативное внедрение

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

Ну и так далее, со всеми остановками.

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

ИТ-директорам, которым удается поддержать именно такой сценарий развития информационной системы предприятия, предлагаю (безо всякой иронии) ставить памятник при жизни. И этот памятник должен символизировать бессмерт­ное изречение: «Надо очень быстро бежать вперед, чтобы оставаться на месте». А для того, чтобы чего-то достичь, нужно бежать ещё быстрей…

Поведенческие индикаторы прогрессора

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

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

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

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

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

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

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

Прогрессоры

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

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

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

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

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

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

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

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

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

Как выбрать прогрессора

1) схожего масштаба с нужной вам тематикой (отлично);
2) схожего масштаба с другой тематикой (хорошо);
3) меньшего масштаба (удовлетворительно).

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

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

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

Спрашивайте всё, что вам интересно, но не забывайте своей цели: вам нужно понять, что именно ваш кандидат создал модель бизнес-процесса, которая результативно внедрена, невзирая на высокую динамику требований в процессе внедрения (еще раз посмотрите на критерии результативного внедрения!). И на всякий случай проверьте, что он подходит под описанный мной «портрет компетенций». Если вы обнаружите сильное несоответствие, то велика вероятность, что вел проект кто-то другой. Попробуйте найти именно его… И наконец, получите весомые гарантии того, что выбранный вами кандидат (именно он!) и будет вести ваш проект до окончания внедрения.

После результативного внедрения

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

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

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

Один в поле не воин

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

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

Внедрение ERP: разбор всех этапов

Автор: Беспалова Алина Николаевна

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

• Что такое система ERP?
• Отраслевое распределение ERP-проектов
• Плюсы и минусы системы ERP
• Цели и задачи внедрения ERP
• C чего начать внедрение ERP? Подготовка и техническое задание
• Разные подходы к внедрению. Этапы внедрения ERP
• От чего зависит стоимость внедрения?
• Проблемы при внедрении ERP
• Какой эффект даст внедрение системы ERP?

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

Аббревиатура ERP расшифровывается как Enterprise Resource Planning. Дословный перевод означает «планирование ресурсов предприятия». ERP – это системы автоматизации, включающие функциональные блоки ресурсного планирования.

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

Именно функция планирования, как часть управления ресурсами предприятия, выделяет системы ERP в отдельный класс.

Отраслевое распределение ERP-проектов

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

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

Рис.1. Отраслевое лидирование при внедрении ERP-систем

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

Для принятия максимально взвешенного и эффективного решения о внедрении необходимо учитывать плюсы и минусы ERP-системы. Преимущества и недостатки ERP-систем в целом схожи. Для конкретики рассмотрим флагманское решение фирмы «1С» – «1С:ERP Управление предприятием».

К плюсам «1С:ERP» можно отнести:

• Функциональность. «1С:ERP Управление предприятием» охватывает практически полностью базовый функционал регламентированного и оперативного учета, а также содержит блоки планирования: финансового, товарного, производственного, кадрового. Возможные к использованию блоки представлены на рисунке ниже (рис.2).

Рис.2. Функциональные блоки «1С:ERP»
Рис.3. Подключение функциональных блоков в ERP «1С»

Минусы «1С:ERP»:

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

Если вы обдумываете возможность внедрения «1С:ERP» и вам требуется более подробная консультация, звоните в нашу компанию по номеру +7 (495) 660-18-12. Специалисты «1С-Архитектора бизнеса» проконсультируют вас по всем интересующим вопросам.

Цели и задачи внедрения ERP

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

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

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

C чего начать внедрение ERP? Подготовка и техническое задание

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

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

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

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

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

Все эти действия, по сути, являются составляющими подготовки к внедрению. На предпроектном этапе в обязательном порядке следует:

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

Эти действия позволят сохранить управляемость проекта на нужном уровне.

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

Цели проекта должны достигаться постановкой требований к системе. Для формирования полного списка таких требований в рамках проекта составляется техническое задание. Техническое задание может составляться как исчерпывающий перечень требований для полного контура автоматизации, а может составляться на отдельный этап (в случае дискретного проекта) или на отдельную работу (в случае абонентского обследования). Сам документ «Техническое задание» в России регулируется ГОСТами:

• ГОСТ 34.602.89 «Техническое задание на создание автоматизированной системы»;
• ГОСТ 19.201-78 «Техническое задание. Требования к содержанию и оформлению».

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

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

Разные подходы к внедрению. Этапы внедрения ERP

Внедрение ERP может проходить по разным сценариям. Несмотря на уникальность каждого проекта, можно выделить три основных подхода к внедрению ERP-систем:

• классический проектный подход;
• внедрение по методу дискретного проекта;
• внедрение в рамках АО (абонентского обслуживания);

Классический проектный подход является приоритетным. В виду сложности системы его можно считать наиболее эффективным. Классический проектный подход включает в себя следующие этапы (рис.4).

Рис.4. Этапы внедрения ERP

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

• Обследование (диагностика). Может проводиться посредством анкетирования или интервьюирования ключевых пользователей (сотрудников предприятия заказчика, уполномоченных в формулировании требований к будущей системе). Наличие управляющей документации на предприятии (инструкций, регламентов) делает этап обследования более эффективным. По итогу обследования должен быть получен исчерпывающий перечень требований, эскиз предлагаемой будущей модели, а также составлена архитектура ИТ-решений с указанием конкретных программных продуктов. По сути, эта информация будет являться техническим заданием на внедрение ERP-системы.
• Моделирование. На этапе происходит тестовая реализация процессов и требований для рекомендуемых программных продуктов, а также уточнение и/или дополнения требований. В отдельных случаях может пересматриваться предлагаемая ИТ-архитектура. Этап крайне важен для успешной реализации проекта. Проводится анализ функциональных разрывов, уточняются «вилки», вырабатывается конкретная методика реализации процессов, определяются участки проектирования.
• Проектирование. На этапе проектирования функциональные разрывы анализируются, объединятся логически и функционально, происходит проектирование будущей системы. Составляются задания на разработку по каждому блоку, форме, отчету.
• Разработка. Происходит разработка по составленным на предыдущее этапе заданиям. Первичное тестирование также является неотъемлемой частью данного этапа.
• Внедрение. Этап внедрения построенной и разработанной системы. Производится обучение по модифицированному функционалу. При необходимости пишутся пользовательские инструкции. Также возможны уточнения разработанного функционала. Тестирование производится, как правило, на неполных данных. Берется наиболее характерная выборка и процессы.
• Опытная эксплуатация. В процессе опытной эксплуатации, как правило, воспроизводится полный цикл работы предприятия за определенный период: чаще месяц или квартал. По результатам этапа выносится решение о готовности модифицированной системы к вводу в промышленную эксплуатацию.
• Промышленная эксплуатация. Здесь очень важным фактором является квалифицированная координация ввода системы в промышленную эксплуатацию. Довольно большой процент предприятий не используют параллельный ввод в ходе промышленной эксплуатации в виду ограниченности ресурсов. Поэтому очень важно организовать готовность всех блоков к работе в оперативном режиме. Данный этап требует почти постоянного присутствия специалиста. Ведь все возникающие вопросы необходимо решать оперативно, часто в онлайн-режиме.
• Постпроектное сопровождение и развитие. Решение периодически возникающих задач в период промышленной оперативной эксплуатации системы.

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

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

Наша компания имеет большой практический опыт и владеет отлаженной методологией внедрения «1С:ERP»: от анализа задач до сопровождения системы. Мы поможем вам сократить время на запуск и освоение программы, избежать ошибок в работе. В рейтинге фирмы «1С» среди Центров компетенции по ERP-решениям «1С-Архитектор бизнеса» занимает третье место.

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

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

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

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

От чего зависит стоимость внедрения?

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

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

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

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

Проблемы при внедрении ERP

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

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

Какой эффект даст внедрение системы ERP?

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

Преимущества от внедрения ERP:

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

Фирма «1С» проанализировала показатели эффективности на основании внедренных проектов «1С:ERP». Эффективность оценивалась руководителями предприятий и участниками команды. Результаты представлены на рисунке ниже (рис.5).

Рис.5. Эффективность внедрения «1С:ERP»

Подведем итоги

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

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

Если вы обдумываете возможность внедрения «1С:ERP» в своей компании и вам требуется более подробная консультация, звоните нам. Специалисты «1С-Архитектора бизнеса» проконсультируют вас по всем интересующим вопросам!

Организация внедрения проекта

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

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

2. ЭТАП 2. Моделирование внедрения проекта 1С

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

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

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

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

Концептуальный дизайн – документ, содержащий описание бизнес-процессов, подлежащих отражению в системе. По сути, это описание системы «To be».

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

Моделирование внедрения проекта системы 1С ведётся по блокам, короткими итерациями при наличии активной взаимосвязи по схеме:

создание модели → демонстрация → корректировка модели

3. ЭТАП 3. Проектирование внедрения 1С

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

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

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

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

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

4. ЭТАП 4. Разработка и тестирование информационной системы

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

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

5. ЭТАП 5. Обучение пользователей типовой конфигурации 1С

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

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

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

6. ЭТАП 6. Подготовка к эксплуатации информационной системы

На данном этапе выполняется:

· развертывание ИС в рабочей среде;

· настройка системы для отражения всех включенных в проект бизнес-процессов;

· настройка прав и ролей пользователей;

· перенос исторических данных из ранее использовавшихся систем;

· интеграция со смежными системами;

· выверка и корректировка данных;

· развертывание системы на рабочих местах пользователей.

7. ЭТАП 7. Опытно-промышленная эксплуатация информационной системы

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

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