Консалтинг

Все верно. Но Вы снова думаете и анализируете в классическом методе.

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

Отражение целей в договоре реализуется при системном подходе тоже очень просто. У нас договор — это 2-4 страницы. Очень простой, ясный и короткий. Его суть — main document, а не полный свод всех правил и взаимоотношений. Самое главное там, что все согласны с: мы делаем — они платят, всегда будут изменения во всех документах, все документы только в электронном виде — бумажные только «копия оригинального электронного документа», время реакции Сторон на любой документ — 24 часа, если нет реакции на документ — он автоматически считается утвержденным, и права собственности на результаты работ: не оплачено — права не переданы, ага и еще алгоритм прекращения проекта. Цели — в отдельном документе, с параметризацией. Впрочем, все в отдельных документах. И оплата строго по графику и по задачам. Выполнено задание — сразу же оплачено (если устраивает). Если не устраивает — реакция и изменения. Совсем работа не устраивает — разошлись. Риски с обеих сторон оценены, и минимизированы. По сути каждая задачка в рамках проекта — отдельный smart contract с системой микроплатежей, иногда на биткойнах. Ой, а у нас бухгалтерия не знает, как платить в электронном виде или что такое биткойн… Вот Вам СТО, как это делать. С проводками и юридическим обоснованием. Люди глупы и верят только в то, что хотят верить. Поэтому, если сделать им СТО — то они сначала всегда скажут, что там все не так. Через 2-3 дня они его изменят и поправят так, как должно быть. Выкинут затраты на кофе секретарю, исправят две точки и три запятых.И очень довольные все подпишут. Пока иначе не было ни разу. Все описано у Норткота Сирилла Паркинсона еще в 1960 году. 

Куча иных аспектов всегда есть на предприятии. Поэтому внедрение ERP делается с полной стандартизацией всех бизнес-процессов. Все бизнес-процессы предприятия доводятся до уровня описания в типовом СТО. Обычно они примитивные и легко укладываются в уже известные модули. Например: была рецептура краски. По ней делают партию в цеху. Но в реальности некоторых компонентов для каждой партии идет немного иное количество, иногда больше загустителя. Было реализовано классическим методом: рецептура и документ, который показывает отклонения от рецептуры для конкретной партии. Плюс документы по расходу материалов со склада в производство. Что порождало изменения проводок в учете. Решение из стандарта IEC 61512: есть мастер-рецептура. В ней отражены теоретические расходы материалов. На основании мастер-рецептуры генерируется рецептура партии. В ней отражены фактические расходы материалов. Генерация идет автоматически по данным дозирования материала в партии, в момент производства. Бухгалтерия видит только рецептуру конкретной партии, причем все компоненты закодированы (еще и безопасность отработана). До мастер-рецептуры они не имеют доступа. Результат: количество событий и документов уменьшилось в 2 раза, бухгалтерия очень довольна (все идет по факту и вовремя), время учета партии сократилось на 30%. 

Так изменения при внедрении (по сути, внедрения типового процесса) изменили процесс на предприятии. Причем все только помогали, потому что ленивые и хотят делать как проще. Чего мы им и дали. Я не шутил, когда писал, что все УЖЕ известно и многократно оптимизировано и описано в стандартах и best practice. И легально купить все стандарты стоит всегда дешевле, чем платить консультантам. И качество выше. Бери и делай. А если работник говорит, что в стандарте не оптимально? Именно для его варианта работы оптимальнее иначе, вот расчет и обоснование? Так это же прелестно! Тогда такой работник берет и сам переделывает стандарт так, как лучше. А делает он это опять же стандартным методом. Принцип — всегда используем изменения для реализации проекта. А не ищем стабильности и неизменности.

Тогда цель для договора с консалтингом – разворачивание ERP-системы в соответствии с ТЗ.

Тоже верно. Только не с ТЗ! А в соответствии с действиями и документами проекта. Или просто в соответствии с проектной документацией. SRS — только часть такой документации. Всегда помним — не один документ определяет логику внедрения. А именно комплект документов! Отвяжитесь вы от этого несчастного ТЗ… Все это уже неактуально. Да, назвать документ можно так, как привык Клиент. Типа это ТЗ!!! А по сути — это комплект документов. И часто не надо утверждать чего-то там у шефа. Работаем параллельно на 5 уровнях. И главное — добиться только правильных контактов, чтобы реакция была на любое событие не более 12-24 часов. И ТОЛЬКО документы. Кстати, все беседы — тоже записываются и подписываются ЭЦП. И это тоже документ проекта, в форме аудиозаписи. Технически все это очень просто, так что можно не экономить. 

И да, прежде всего приходится делать стандарты для себя, для Исполнителей проекта. Если их нет — то проект тоже можно внедрить. Если конкретный человек и будет таким стандартом. Метафора у Брукса, хирургическая бригада. Но только малые и быстрые проекты! Даже не пытайтесь делать так, если предприятие не дозрело до таких методов. Риски очень высокие.