ERP Внедрение заметки

Все верно. Но есть и иной подход.

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

Смотрим на эти процессы, как га модель системы в одном аспекте.

Строим эту модель очень простым способом: все НЕОБХОДИМЫЕ процессы просто соединяем на схеме последовательно. Модель из теории надежности. Последовательная система. Элементы модели — только функции (действия). Получаем парсингом (семантическим анализом?) из use-case. Эта модель показывает, суть работы: при поломке любого процесса вся система выходит из строя.

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

Далее анализируем уровень развития каждого элемента. Метод: взвешенный экспертный анализ. По трем параметрам каждый элемент: время — качество — деньги. Ничего нового, параметры из треугольника проекта. Находим наихудший элемент. Их будет несколько, потому, что параметра 3. Получим точное определение «бутылочного горлышка». Обычно оно и так известно на предприятии. Просто о нем не говорят…

Далее внедряем стандарты процессов именно для этих элементов. Там приколов масса, но можно сделать так, чтобы люди сами помогали. И да, внедрение возможно ТОЛЬКО через построение параллельной цепочки элементов. В имеющихся элементах менять ничего нельзя! По сути, дублируем часть функций. Самый прикол: можно даже старые методы использовать. Пока никаких MRP. Например, это часть процессов Закупки.

Далее расширяем границы системы внедрения, пока не станут близкими по очертаниям к стандартному модулю Закупки из системы MRP. Будет несколько больше элементов, чем в начале, ну и фиг с ними. Опять, все стандартизируем и типизируем. Опять же на основе любимых ISO и иных стандартов. Ну и психолог нам в помощь! Люди все-таки работают на местах, куда же без психологии.

Уже можно ставить почти ВСЕ модули MRP. Обычно, Закупки, Продажи, Склад, Финансы, Учет, какой-то центральный модуль. В разных системах немного по-разному, но разобраться несложно. Только то, что удобно и не будет проблем с инсталляцией потом. И да, лучше всего сразу все в «облаке». И да, все сопли насчет безопасности идут лесом. Не всегда, но почти в 70% случаев системы безопасности в облаке построены не в пример лучше, чем на предприятии. Это отдельная песня, тема целой статьи.

Но запускаем только Закупки. Там, где все стандартизировали. Всегда помним: «Первый шаг должен быть наиболее ЭФФЕКТНЫМ». Не путайте с эффективным! Это разные слова. Вот проект по внедрению MRP и закончен. Все.

Далее — следующий проект. Расширение функционала ИМЕЮЩЕЙСЯ системы MRP. Звучит совсем по-иному, иные риски и иная логика работы. Все пусть делают местные сами, по Вашим шаблонам, по Вашим стандартам. Главное: 70% времени и сил пусть Заказчик в проекте сам и тратит. По накатанной колее все летит со свистом. Опять же, последовательность внедрения — по наихудшим элементам в первую очередь.

И всегда помним о стандартах процессов: Вы их даете, Вы их адаптируете, чтобы все процессы Клиента выполнялись по таким типовыми процессам. Если нет такого процесса в наборе стандартных процессов — значит плохо искали! Не бывает таких вариантов! Никогда.

Когда процесс заработал — его можно автоматизировать.

Внедрение MRP — это именно стандартизация и отработка процессов на базе ИТ систем. Логика работы процессов работы в ИТ системах уже построена, она оптимальная. Это и есть те кубики конструктора, из которых строим систему для Клиента.

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

А для этого надо знать типовые процессы бизнеса ЛУЧШЕ, чем Клиент. А с этим всегда дым и чад… Для того стандарты и публикуют. В них — отражение лучших практик в этой отрасли. Или хотя бы основы для подхода к проблеме.

Прекрасно! Благодарю за информацию!

Мне довелось быть с обеих сторон разных проектов. В том числе нескольких внедрений информационных систем.

Не пишу ERP, потому что это не важно, как назвать информационную систему. Можно MRP ERP CRM 1C SAP G Suite… И да, это все совсем разные системы. Но есть у них много общего.

Прежде всего, взгляд с другой точки зрения на одну фразу из Вашего поста:

«Так вот, цель проекта – внедрение ERP-системы. „

Нюанс именно в формулировке цели. Из 27 опрошенных мною лично людей, 26 формулируют цель так: “глагол + существительное.» Например, цель школы: «получение знаний». В Вашем варианте: «внедрение системы».

Почему это ОЧЕНЬ важно: так запрограммирована голова у 99% людей. И именно поэтому очень часто возникают проблемы при реализации любого проекта. В том числе проекта ИТ. И это свойство разума есть не только в России, но и в Польше, например. Откуда это — особая тема, скажу только, что корни в редукционистском подходе в мышлении, в противовес холистического (целостного) подхода.

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

Корректнее цель формулируется только существительным (можно с прилагательным, указателем свойства). И тут самый прикол: «система ERP» — вовсе не цель проекта. «Время одной продажи» — цель проекта. «Время составления заявки» — цель проекта. Значение целевого параметра «Время одной продажи» = 30 минут. Так проще и легче. Целей может быть много, но если все они выражены через существительные, то начать и ЗАКОНЧИТЬ проект внедрения с успехом — очень просто.

Оценка вариантов, консалтинг, и самое страшное — ТЗ. Можно все придумывать и набивать самому шишки.

Так БЫЛО когда-то, лет так 10 назад. Если же сейчас кто-то заикается о «Разработка технического задания» — то лучше сразу бежать как можно дальше. Причина: давно уже стандартизирован системный подход (в отличие от классического). IEEE software life cycle, там все описано. Логика совсем иная, подход холистический, одновременно в разных аспектах (аспекты по ISO 81346). И там нет ТЗ. От слова «совсем».

Насчет документов проекта: если Исполнитель прислал Заказчику SRS в виде ссылки на документ Гугла, причем на 70% SRS уже заполнен — то это профессионалы. Если сразу создали Карту проекта, План работ, Список документов проекта (main document по ISO 11005), дали доступ к стандартам Исполнителя, в которых написано, как все это заполнять — то можно начинать внедрение с таким Исполнителем. Если приходят, звонят, присылают документы по электронной почте, назначают встречи — то проект скорее всего будет провален или затянут от плана в 10 раз.

Далее, а что там у Заказчика? У Заказчика баланс на каждый день. Есть СТО (причем Стандарты процессов, а не только продуктов!), шеф Заказчика умеет пользоваться облачными сервисами, не печатает документы, в фирме пересылают документацию в налоговую с использованием ЭЦП. И самое главное: у шефа фирмы только один сотовый телефон, причем не iPhone. Тогда есть шанс, что можно внедрить у них информационную систему. Если хотя бы один пункт не выполнен — то будут проблемы и проект не закончим.

Почему так? Потому, что с 2008 года во всем мире ВСЕ процессы (в том числе и абсолютно все бизнес-процессы) построены по готовым стандартам.

От типовой модели организации (из тех же стандартов ISO, модель событийная, потоковая). То есть как именно должны быть построены все бизнес-процессы в фирме из определенной отрасли. Ничего не надо придумывать и даже пытаться понять, как сделано сейчас у Заказчика. Все равно, что бы не придумал Заказчик в своей фирме, все, что придумают 100500 консультантов вместе с Заказчиком, все знакомые этих консультантов, знакомые их знакомых — все это УЖЕ есть, описано, оптимизировано, в виде моделей до уровня «поле такое-то, тип текстовый, 256 символов» в соответствующем стандарте. То есть совершенно до таких деталей, что аж офигеваешь…

Например, периодические процессы производства описаны в стандарте IEC 61512 с деталями организации как технологии, так и архитектуры системы. Например, для проекта по краске мы использовали около 15% возможностей, там описанных. И этого хватило для всех технологов и «манагаров» и экономистов, и бухгалтеров, и директоров всех уровней. Были ОЧЕНЬ рады, что рецептуры теперь совсем иначе делаются, намного проще, удобнее, и быстрее. Время создания комплекта документов сократилось с 240 до 40 (!!) нормочасов. И это только применение стандартных ПРОЦЕССОВ! Как эти процессы соединить между собой — тоже все уже описано и стандартизировано в виде best practice. И на основании типовых схем собираем цепочку для получения нужного продукта. Какого? А тут полная воля для Заказчика и для всех его “манагаров”. Любого продукта. Но по стандартным процессам!

Нужно ERP подключить? Очень просто! Стандартная структура фирмы по определенному ISO для конкретной отрасли. Плюс стандартные процессы по тем же стандартам ISO, плюс стандартные желания и требования Заказчика (которые всегда будут не более, чем 15% от тех же стандартов ISO). И стыкуем по стандартной модели из стандарта IEC 62264. И такт стандарты и готовые модели и рекомендации есть по КАЖДОМУ процессу по каждому элементу бизнес-системы у Заказчика.

Никогда еще мне не пришлось столкнуться, чтобы Заказчик чего-то придумал такого, чего УЖЕ нет в стандарте на какой-то процесс. Поэтому внедрение ERP MRP и подобных систем — тупая рутина, типа как внедрение «текстового редактора» у себя дома.

Не парьтесь! Изучайте системный подход, стандарты типовых ПРОЦЕССОВ из ISO IEC IEEE ANSI EN BS, выкиньте кривые ГОСТы (они устарели лет на 15 минимум), а всех, кто говорит про ТЗ — отправляйте в пешее эротическое путешествие.

Прелестно!

Это и есть один из стандартов процесса внедрения. Открою один секрет: ВСЕ ERP а также ИС сделаны по определенным моделям и стандартам ISO IEC IEEE. И буржуи просто не понимают, что вы от них хотите? Нафига вообще говорить и спрашивать о каких-то требованиях??? Для них — это нонсенс!

А делает ли ваша система то и это? Конечно делает, это же есть в стандарте. Зачем спрашивать? Если написано ERP — значит система реализует планирование (P) ресурсов ® на уровне группы предприятий (холдинга) (E). МОДЕЛЬ такого планирования описана в стандарте. В чем прикол, зачем спрашиваете?

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

Да примитивно там все до невозможности! Поэтому нет смысла делать такие спецификации SRS. Просто переписывать стандарт туда IEC 62264? Зачем? Дешевле купить готовый перевод и не заморачиваться.

Не понятно что там написано? А это уже отдельная песня… В этом случае ни ТЗ (будь это слово трижды проклято в программировании), ни договора не помогут.

Внедрение, работа и практическое использование информационных систем ВСЕГДА построено на системном подходе. А 99% предприятий и руководителей в России пользуются в работе классическим подходом. Аналогия: классический подход — это черчение детали на листе бумаги в двух измерениях. Системный подход: разработка детали, через компьютерное моделирование ее изготовления, в трехмерном пространстве. Лист бумаги и карандаш — и система типа SolidWorks. Можно из SolidWorks получить чертеж на бумаге? Можно! Но это будет только 1% от возможностей системы. И чертеж нафиг не нужен! Потому, что все равно деталь будут печатать на 3D принтере.

Вот такая аналогия родилась… Так точно все и в системе ERP! «А можно накладную заполнять снизу вверх?» — да, можно. Но нафига это нужно? Даже накладные не нужны в новой системе. Вот в чем прикол! И да, это элементарно стыкуется с ПБУ и бухучетом. И да, я это много раз делал в России и в Европе. И да, ВСЕ вопросы бухгалтеров, налоговых инспекторов, проверяющих всех рангов, аудиторов решаются моментально. И да, все строго по методологии бухучета, действующему законодательству и обычаям делового оборота. Только одно требование к получателю информации есть: умение читать и зачатки разума. Все остальное обосновано на всех возможных уровнях. Поэтому вариант только один — учить матчасть в виде стандартов. Все равно применять придется. Так или иначе, рано или поздно.