Текст книги "Введение в управление проектами внедрения ERP-систем"

Рассмотрим отдельно и подробнее такое важное понятие, как проектный треугольник, или «треугольник управления проектом».

Условно его идею можно сформулировать в одну строку:

«Быстро – Качественно – Дешево: выберите любые два пункта».

Из этого получается:

● хочется быстро и качественно – будет дорого;

● нужно дешево и качественно – будет долго;

● нужно быстро и дешево – будет, очевидно, некачественно.

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

Все эти величины имеют верхние пределы:

● разумный срок, далее которого проект автоматизации теряет смысл: система устареет, бизнесу жить годы без автоматизации тяжко;

● конечное количество денег у компании, которое она готова заплатить за проект;

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

Рис. 3.4. Проектный треугольник

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

Внесение изменений в одну из сторон треугольника меняет как минимум еще одну связанную сторону.

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

Далее в таком треугольнике проявляется конфликт интересов заказчика и исполнителя:

● Цели заказчика проекта: сделать побольше (увеличить объем работ), побыстрее (сроки сократить), подешевле (меньше ресурсов потребуется).

● Цели исполнителя: заработать максимум денег, закрыть потребности заказчика в приемлемом качестве. А это: сделать поменьше (минимизировать объем работ), подольше (увеличить срок, чтобы все успеть без авралов), подороже (увеличить бюджет).

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

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

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

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

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

В общем случае получается четыре подхода:

● Фиксируем объем работ: меняем сроки и бюджет проекта.

● Фиксируем бюджет проекта: меняем сроки и объем работ.

● Фиксируем сроки: меняем объем работ и бюджет проекта.

● Меняем все стороны треугольника.

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

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

Графически это можно представить на схеме.

Рис. 3.5. Разница между гибким и «водопадным» подходами

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

3.3.Реинжиниринг бизнес-процессов

Один из важных моментов процесса внедрения ERP-системы – это возможность взглянуть свежим взором на привычные, устоявшиеся за годы (а может, и десятилетия) бизнес-процессы.

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

Логично предположить, что раз компания созрела для внедрения ERP-системы (так как ее не было вообще или существующая не соответствует потребностям), то на это были причины. В главе 1 в разделе «Зачем ERP-система компании» такие причины рассматривались.

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

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

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

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

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

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

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

3.4.Какие подсистемы в какую очередь внедрять

Еще один важный аспект темы «как внедрять ERP-систему» – это какие именно подсистемы из ERP-системы внедрять и в какой очередности.

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

Составив схему текущего и перспективного ИТ-ландшафта (см. главу 2, раздел «ИТ-ландшафт текущий и перспективный»), можно рассмотреть возможные варианты перехода от одного состояния к другому:

● Полная замена текущих систем на новую ERP («все и сразу»).

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

Текущие учетные системы или их аналоги, до того неавтоматизированные блоки (например, в файлах Excel) при полной замене и переходе в единую ERP-систему просто перестают использоваться, и идет переключение (одномоментно) сотрудников на работу в новую систему. До переключения на новую систему, разумеется, прошли фазы анализа, настройки, переноса начальных данных и, главное, обучения пользователей (подробнее о фазах проекта будет рассказано в следующих главах). До момента переключения все работает по-старому, после переключения – по-новому. Тут вроде все понятно. Новая система обеспечивает полный «замкнутый» цикл учета по всем основным бизнес-процессам, что планировались к автоматизации.

А что делать, когда так поступить невозможно (сроки/ресурсы/объем работ не позволяют, см. раздел «Проектный треугольник») и принимается решение о запуске частями? Как эти «части» определить?

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

ERP-система состоит из связанных между собой блоков (см. рис. 1.1), запуск которых в работу возможен не всех сразу, а в некотором сочетании между собой. Так, в 1C: ERP настройками функциональных опций некоторые разделы (подсистемы) можно вообще скрывать или отключать функциональность частично – например, не использовать платежный календарь и заявки на расходы денежных средств в «Казначействе», а пользоваться только учетном денежных средств и интеграцией с клиент-банком.

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

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

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

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

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

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

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

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

● Например, подсистему «Бюджетирование» хочется начать использовать, но до внедрения ERP в компании не было процессов бюджетирования, значит, этот блок можно отложить на вторую очередь. Если, конечно, это не основная цель автоматизации.

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

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

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

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

Рис. 3.6. Подсистемы из новой ERP-системы дополнительно к текущей учетной системе

В этом случае:

● оставляем текущую учетную систему,

● рядом ставим 1C: ERP,

● настраиваем одно– или двустороннюю интеграцию систем,

● внедряем новые подсистемы из 1C: ERP в компании,

● получаем ожидаемый эффект от нововведений.

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

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

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

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

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

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

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

Вариант 1. Запуск от оперативного контура.

Рис. 3.7. Запуск от оперативного контура

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

Вариант 2. Запуск от бухгалтерского учета.

Рис. 3.8. Запуск от бухгалтерского учета

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

Вариант 3. Запуск от финансового планирования и МСФО.

Рис. 3.9. Запуск от финансового планирования и МСФО

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

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