8 (800) 500-61-51

8 (495) 600-61-81


Независимый аудит проекта 1С

Компания ИТРП выполняет независимый профессиональный аудит проектов внедрения 1С на производственных предприятиях.

Аудит предполагает анализ трех составляющих проекта:

  • организационной,
  • методической,
  • ресурсной.

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

Источниками рисков могут быть:

  • Исполнитель
  • Заказчик
  • Внешняя среда

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

Список типовых рисков внедрения ERP-системы достаточно обширный.

Обзор рисков проекта 1С>>>

Выполнение аудита

Аудит проекта включает следующие работы:

  • Анализ существующей проектной документации.
  • Анализ внутренней документации предприятия.
  • Интервью с представителями Заказчика и Исполнителя проекта.
  • Формирование выводов о причинах и источниках кризиса.
  • Выработка рекомендаций по выходу из кризиса, в т.ч.:
    • организации проекта, проектной технологии и плану работ,
    • методические рекомендации по реинжинирингу бизнес-процессов и использованию типового решения «1С:ERP Управление предприятием 2».
  • Рекомендации Заказчик получает в виде «Отчета об аудите проекта».
  • Контроль выполнения рекомендаций, обратная связь на руководство предприятия.

Также в рамках аудита возможно дальнейшее кураторство проекта для защиты интересов Заказчика.

По желанию Заказчика компания ИТРП может взять на себя выполнение дальнейших работ по проекту в части подсистемы «Управление производством».

Уточнить стоимость аудита:





Организационная часть аудита

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

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

  • Заказчика заманили на проект низкой ценой и короткими сроками, а на поверку оказалось что подрядчик подразумевал внедрение типового функционала без детального анализа особенностей предприятия, бизнес-процессов, специфических задач заказчика.  В результате, так как нужно Заказчику — система не работает. На претензии пользователей внедренцы отвечают «Скажите что вам нужно, тогда мы доработаем«. Но Заказчик не знает, как правильно сформулировать то, что ему нужно. Для этого ему нужна помощь консультантов, а это дополнительные расходы…
  • Противоположная ситуация. Заказчик требует скрупулезного изучения бизнес процессов и систему «под ключ», в которой учтено ВСЕ. Проект выполняется долго, до бесконечности выясняются нюансы бизнес-процессов, наработано множество отчетов по моделированию и ТЗ, процесс утонул в согласовании отчетов, ТЗ и прочей документации. Практических результатов нет, а расходы на проект растут…
  • Реализовано/доработано немного не то, как это хотел и видел Заказчик, но в ТЗ были неоднозначные формулировки. За дополнительные доработки Подрядчик  просит дополнительную оплату. Заказчик считает, что недоработки должны быть устранены бесплатно. Ведь подрядчик — специалист в области ИТ и сам должен был все предусмотреть. А подрядчик заявляет что телепатией не обладает и мысли клиента не читает. Что просили — то и сделали.
  • Подрядчик заявляет, что его плановая трудоемкость разработки ТЗ или реализации доработок полностью выбрана и требует доплатить (это уже совсем крайний случай).
  • Не удается организовать пользователей на выверку данных и ввод информации в параллельно работающей системе в период опытной эксплуатации. Процесс затягивается.
  • Внедрили одну подсистему, решая только локальные задачи (например, бухгалтерский учет). На внедрении следующего блока — управления складом или производства — оказалось, что бухгалтерский блок надо полностью перерабатывать. Это происходит потому, что на первых этапах внедрения не думали о требованиях следующих по очереди блоков. Не всегда самые простые задачи следует внедрять в первую очередь, пусть даже с целью показать  быстрее  практический результат.
  • В процессе разработки ТЗ Подрядчиком (по договору подряда, с жесткими стоимостью и сроками) у Заказчика изменилось видение проекта. Потенциально конфликтная ситуация — Подрядчик следует первоначально определенному плану и не желает слушать Заказчика, пока не будут подписаны акты по выполненным текущим работам. Которые, возможно, Заказчику уже не нужны…
  • Продажей проекта занимался специалист высокого класса, и Заказчик доверился компании. Но проект пришли выполнять малокомпетентные специалисты-стажеры. Для заказчика это ключевой проект, а для стажеров подрядчика — практикум для повышения квалификации.  Подрядчик  занимается обучением своих специалистов за счет Заказчика.
  • «Партизанская война» пользователей против новой системы — пытаются работать вне новой системы (например, отчеты сдают в Excel), о проблемах никому не докладывают, не дают обратную связь. Проблемы в системе остаются, что дает пользователям повод и дальше ее игнорировать и сигнализировать руководству классической фразой «Ничего не работает«….
  • Система внедрена, но Заказчик не видит никаких выгод от автоматизации. Прибыль не выросла, качество обслуживания клиентов не возросло, пользователям работу усложнили и так далее.

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

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

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

Методическая часть аудита (научно-технический совет)

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

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

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

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

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

О методах моделирования можно прочитать здесь:

http://itrp.ru/questions/notatsiya-opisaniya-biznes-protsessov-aris-eepc/

http://itrp.ru/questions/notatsiya-opisaniya-protsessov-bpmn/

Ресурсная часть аудита

Для выполнения ERP-проекта Заказчик должен располагать необходимыми ресурсами:

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

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

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

Ошибкам Заказчиков при подготовке НСИ посвящен наш вебинар:

http://itrp.ru/video/formirovanie-normativno-spravochnoj-informatsii-v-1s-erp-2-0-vebinar/

Если остались вопросы

Задать вопрос специалисту по аудиту





Материалы по теме

Проверьте организацию вашего проекта. Скачать чек-лист>>>

Гибкие технологии Agile/Scrum — панацея?>>>

 



Нет времени читать? Нажмите на кнопку и сохраните у себя статью:

 

Проекты и решения на 1С для производства

1С:ERP, 1C:УПП, 1С:MES, 1C:ТОИР

Заказать демонстрацию

Предсказуемое внедрение.
Гарантированный результат.
Выверенные технологии внедрения.

Подробнее

Ближайшие вебинары, курсы, конференции

Получайте расписание новых мероприятий на свою электронную почту

Подписаться

Обсудите вашу задачу с нашим специалистом

Сможем ли мы решить именно вашу задачу? Сколько это будет стоить? Сколько времени займет проект?
Оставить заявку
youtube.complus.google.comvk.com
-->