Дисклеймер: пост не претендует на объективность. Исключительно субъективное мнение на основании не слишком большого опыта внедрения ERP на стороне клиента. В статье описаны некоторые действия, которые желательно сделать до заключения контракта на внедрение ERP-системы.
Что такое «консалтинг»?
Предлагаю для начала определиться с терминологией.
Мне кажется при внедрении ERP представители бизнеса несколько по-иному понимают понятие «услуги консалтинга», чем представители компании-исполнителя. Давайте попробуем внести ясность. Определение из Википедии:
«Консалтинг (консультирование) — деятельность по консультированию руководителей, управленцев по широкому кругу вопросов в сфере финансовой, коммерческой, юридической, технологической, технической, экспертной деятельности. Цель консалтинга — помочь системе управления (менеджменту) в достижении заявленных целей.»
Так вот, цель проекта – внедрение ERP-системы. Именно это прописывается в договоре с исполнителем. В рамках проекта внедрения консультанты НЕ будут выполнять аудит и реинжиниринг бизнес-процессов как таковых.
В рамках проекта внедрения ERP консультанты выполняют анализ существующих процессов и пожеланий пользователей для их корректного отражения в новой системе, не более того. Операции, выполнение которых планируется вне системы, вообще выпадают из зоны их внимания.
Как правило, всесторонний аудит процессов с целью достижения определенных бизнес-показателей (например, сокращение товарных остатков, сокращение времени поставки клиенту) выполняют консалтинговые компании другого профиля по отдельному договору и за отдельные деньги.
Действительно, при внедрении ERP происходит «оптимизация…, повышение…, минимизация…» бизнес-показателей, но это происходит только, если выполняется хотя бы один из пунктов ниже:
- автоматизируются процессы, ранее выполняемые вручную или не исполняемые вовсе;
- заказчик четко понимает, какую новую логику/структуру/наполнение он хочет заложить в процессы новой системы и какой выигрыш планирует получить от этого. Другими словами, заказчик сам (или с помощью сторонних компаний) провел аудит бизнес-процессов с целью оптимизации бизнес-показателей и у него есть желание отразить полученные рекомендации во внедряемой ERP системе;
- стандартные процессы внедряемой системы устроены на порядок лучше, чем текущие процессы заказчика. И заказчик готов подстраиваться под эти процессы;
Если в процессе внедрения будет простое переложение процессов из имеющихся систем в новую ERP без существенных изменений в логике – не нужно ждать прорывных улучшений по бизнес-показателям. Т.е. предлагаю не путать консалтинг непосредственно бизнес-процессов и консалтинг процессов при внедрении ERP-системы. Впрочем, иногда консультанты и при внедрении ERP предлагают красивые нетривиальные решения для бизнес-задач, но это все-таки больше исключение, чем правило на проектах внедрения.
Что нужно сделать ДО заключения договора с консалтинговой компанией
- Сформулировать цель проекта и донести ее до всех представителей бизнеса, кто будет причастен к проекту. Вот только не надо обтекаемых формулировок типа «повышение эффективности деятельности предприятия за счет внедрения ERP». Пусть эти эпистолярные упражнения остаются на откуп внедренцам, уж что-что, а составлять такие формулировки для договора они умеют все: не каждый проект по внедрению ERP успешен, но для каждого проекта еще в самом начале декларируются красивые цели, достижение которых не всегда можно однозначно замерить при завершении проекта.
Нужно простыми словами пояснить и бизнесу, и компании-исполнителю зачем необходима ERP–система. Ведь что-то же сподвигло рассматривать вопрос о ее внедрении? Что именно? Зачем? Необходимо сформулировать эту мысль и изложить на бумаге.
На предприятии все должны понимать для чего внедряется новая система, какие улучшения она должна принести на предприятие, насколько сильно изменения коснутся конкретных подразделений бизнеса.
В этом случае бизнес будет понимать ради чего вся эта свистопляска с дополнительной нагрузкой в виде общения с консультантами, изучения толстых документов с непонятной терминологией, необходимости изучения нового софта и т.д. Особенно это актуально для подразделений, в чьей работе не предвидится каких-либо кардинальных изменений и для них смена самописки на промышленную систему выглядит как мена шила на мыло. На одних только вопросах и стенаниях консультантам типа «А зачем вы внедряете нам свою систему?», «А нас всех уволят после внедрения вашей системы?», «У нас все хорошо работает, не надо нам ни чего внедрять!» и т.д. можно сэкономить значительное количество дорогого консультантского времени.
Изначально сформулированная цель будет полезна и исполнителю. Это поможет консультантам понять вектор, в направлении которого заказчик желает развиваться, применять «правильные» критерии при выборе конкретного варианта решения задач из нескольких возможных, упростит налаживание продуктивных контактов с пользователями.
- Составить перечень необходимой функциональности к новой системе. Как правило, эта работа выполняется во время подготовки договора на внедрение консультантами, но на мой взгляд, клиенту это лучше начать делать самостоятельно еще до начала общения с потенциальными исполнителями. В наших реалиях ситуации бывают разные, может проект инициироваться на дружеской вечеринке ТОПов с фразы «Нам тут производство нужно автоматизировать. Возьметесь?». И даже хлопнут по рукам, а потом линейные сотрудники компании интегратора осознают, что заказчик под автоматизацией производства понимал «не совсем» производство в ERP, а что-то из списка ниже:
- Интеграцию производственного оборудования с ИС. При чем в качестве управляющей системы заказчик подразумевает имеющуюся самописную систему;
- Позаказный учет затрат на производстве;
- Автоматическое формирование последовательности производственных заказов с учетом имеющихся ограничений;
- Планирование производства на длительный горизонт на основе плана продаж (который тоже нужно автоматизировать в новой системе. А разве это не само собой разумеющееся?) с возможностью варьировать параметры и выбирать наиболее оптимальный план производства.
Это не всякому IT-специалисту понятно, что не все вышеперечисленные задачи решаются в ERP-системе, но откуда это знать директору производственного предприятия, отлично разбирающемуся в производстве и продажах ТНП, но далекого от IT? Надеюсь вашей фантазии хватит для того, чтобы представить насколько анекдотично развиваются такие ситуации в реальности: ни кто же не возьмется вслух сказать, что ТОПы не правы (один в постановке задачи, другой в ее оценке).
Поэтому перечень требований к функциональности системы:
- способствует взаимопониманию между заказчиком и исполнителем;
- позволяет исполнителю сделать более точный расчет по цене и срокам;
- сокращает время подготовки договора со стороны исполнителя: эти требования могу стать основой для раздела «Функциональный объем проекта» в договоре;
- позволяет осознать свою долю ответственности за проект владельцам бизнес-процессов. По моему мнению, внутренние IT-специалисты компании могут и должны привлекаться к этой работе, но ответственность за полноту первоначального списка, как и за полноту «Функционального объема проекта» в договоре должна лежать именно на владельцах бизнес-процессов.
Еще важно, чтобы в этих требованиях было указано что должна делать система, но не нужно описывать как это должна делать система. Определить и описать каким образом в новой системе будут реализовываться процессы – это уже полностью задача консультантов. И совершенно не факт, что процессы в новой системе будут выглядеть так, как их на начальном этапе представляет бизнес.
- Попросить референс-визит. Вряд ли получится организовать референс-визит в компанию конкурента, а вот в компанию совершенно из другой отрасли – вполне возможно. Можно заранее проанализировать, какие процессы могут быть похожи и уделить им особое внимание, отсекая работы, совершенно не релевантные. Например, если у вас производство бытовой химии, вряд ли вам хоть чем-то поможет референс на машиностроительное производство (хотя в части HR – как знать), но при визите на предприятие пищевой промышленности уже можно почерпнуть что-то полезное, например, в продажах, отгрузках, в работе с дебиторкой.
Альтернатива референсу — демонстрация каких-либо важных процессов в уже настроенной системе. У компании-интегратора могут быть свои учебные и/или тестовые базы, на которых они могут продемонстрировать какие-либо типовые процессы.
Даже если будут показаны / продемонстрированы процессы, совершенно не пригодный для использования на проекте, но при этом у заказчика появятся более конкретные вопросы относительно реализации, и он получит исчерпывающие ответы на эти вопросы – это не будет бесполезной тратой времени.
- Оценить различные варианты внедрения системы – поэтапный и «все сразу».
При сравнении стоит обратить внимание на следующие моменты:
- Объем и сложность интеграции. Абсолютно понятно, что поэтапный вариант имеет больший объем интеграции за счет временных интерфейсов. И сравнивать по этому критерию «большой взрыв» и «слона, разделанного на кусочки» бессмысленно, результат известен априори. Имеет смысл сравнивать между собой несколько вариантов поэтапного внедрения. Возможно, по этому параметру можно найти более оптимальный вариант, чем тот, который кажется очевидным при первом взгляде на процессы предприятия. Для проработки этого вопроса желательно привлечь эксперта со знанием архитектуры внедряемой системы и знатока существующих IT-систем предприятия.
- Необходимость модернизации старой / развертывание новой инфраструктуры. Для организации инфраструктуры, соответствующей потребностям проекта, необходимы время и деньги. При разных вариантах внедрения – разное количество времени и денег. Инфраструктура — из самых очевидных задач, сопутствующих проекту внедрения. Но удивляет количество случаев, когда ей не устанавливают должного приоритета, а то и просто забывают.
- Планы предприятия на естественное развитие, например, ввод в эксплуатацию новых складов, закупка нового оборудования, выход на новые рынки. Необходимо проанализировать, каким образом эти планы накладываются планы по внедрению системы и как эти планы влияют друг на друга.
- Объем и сложность интеграции. Абсолютно понятно, что поэтапный вариант имеет больший объем интеграции за счет временных интерфейсов. И сравнивать по этому критерию «большой взрыв» и «слона, разделанного на кусочки» бессмысленно, результат известен априори. Имеет смысл сравнивать между собой несколько вариантов поэтапного внедрения. Возможно, по этому параметру можно найти более оптимальный вариант, чем тот, который кажется очевидным при первом взгляде на процессы предприятия. Для проработки этого вопроса желательно привлечь эксперта со знанием архитектуры внедряемой системы и знатока существующих IT-систем предприятия.
Надеюсь, что моя статья уменьшит количество вопросов «А что, и так можно было?» на чьем-либо проекте.
Комментарии (26)
surVrus
03.08.2017 22:24+1Прекрасно! Благодарю за информацию!
Мне довелось быть с обеих сторон разных проектов. В том числе нескольких внедрений информационных систем.
Не пишу 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 минимум), а всех, кто говорит про ТЗ — отправляйте в пешее эротическое путешествие.Dementor
03.08.2017 23:18-1Получил две статьи по цене одной :)
А вы не хотели бы осветить работу со стандартами более широко, возможно в виде статьи? Тема интересная, особенно в свете ваших слов «Потому, что с 2008 года во всем мире ВСЕ процессы (в том числе и абсолютно все бизнес-процессы) построены по готовым стандартам.»
Изучайте системный подход, стандарты типовых ПРОЦЕССОВ из ISO IEC IEEE ANSI EN BS, выкиньте кривые ГОСТы (они устарели лет на 15 минимум)
И тем не менее гугление по вашему стандарту IEC 61512 выдает именно ГОСТ Р МЭК 61512-1-2016, который создан на базе IEC 61512-1:1997surVrus
04.08.2017 10:00Благо дарю за ответ!
Уже пишу статьи. Будет не одна, а скорее всего много. Материл есть, надо причесать и некоторые части перевести с польского и английского.
pebble Автор
03.08.2017 22:26Да, везде указывают, что цель должна быть измеряема. Но вот досада, я до сих пор не умею формулировать короткие, ясные и измеримые цели. Либо коротко и ясно, но из формулировки не понятна измеримость,
либо с описанием необходимых ограничений и целевых параметров, но это уже выливается в отдельный документ и больше похоже на требования к системе, чем на цель.
Поэтому была бы благодарна, если Вы сможете привести, корректный по вашему мнению, пример цели при внедрении именно ERP-системы. Пример про «Время одной продажи = Х минут» не считаю подходящим — слишком однобокая формулировка для системы, поддерживающей большое количество БП.msin
03.08.2017 23:01Цель кратко — Оптимизация управление ресурсами предприятия (повышение рентабельности)
Более развернуто:
— Сокращение/оптимизация запасов сырья и готовой продукции
— Сокращение производственного цикла
— Увеличение выпуска продукции (если рыночный спрос превышает выпуск)
Все эти пункты очень хорошо измеряются и могут легко быть проконтролированы.
Типичные результаты внедрения реально работающей ERP дают коэф. примерно 2 по каждому пункту
(понятно, что везде есть специфика и нюансы)surVrus
04.08.2017 00:46Цель — существительное (продукт).
«Ресурс заменяем на сырье». То, что на входе предприятия. Причина: слово «ресурс» обозначает что-то иное, особенно в Управлении проектами. Может быть путаница. Используем стандартное определение (словарь) для производства на основе периодических процессов (IEC 61512)
Более корректно:
1. Оптимальное количество сырья. Значение: на 7 дней работы для каждого вида.
2. Оптимальное количество продукта. Значение: на 7 дней продаж для каждого вида.
Цель — глагол (процесс)
3. Сокращение (при цели 1). За 1 месяц на 50%.
Тогда можно проконтролировать и измерить. Если соединено все вместе — то невозможно. Попробуйте параметризировать цель «Оптимизация управление ресурсами предприятия (повышение рентабельности)». Хотя бы один параметр, не разделяя семантически само предложение. Я не умею.
То же самое про рентабельность. «Оптимизация управление ресурсами предприятия (повышение рентабельности)» Тут сразу три аспекта: функции, продукт, финансовый. Причем цель сразу связан с методами. Оптимизация — ресурсы. Повышение — рентабельность. Корректно стоит разделить на три части.
Рентабельность — неприменимый показатель в этом контексте. Не указано рентабельность чего именно: продукта, деятельности за квартал, всего предприятия.
Корректно наверное так:
Цель:
Рентабельность ROE Значение:+20% от ROE.2017
Рентабельность ROS Значение:+10% от ROS.2017
Рентабельность ROA Значение:+15% от ROA.2017
Цель:
Повышение для ROE До целевого значения. март 2018
Повышение для ROS До целевого значения. март 2018
Повышение для ROA До целевого значения. март 2018
Вот тогда можно измерить и проконтролировать.
И еще для каждого нужно указать метод измерения. Например СТО…
surVrus
04.08.2017 00:54Извините, совсем забыл.
Цели у Вас msin указаны и сформулированы совершенно правильно!
Просто Вы используете одну методологи. (классический метод).
Я использую системный подход (холистический метод).
Оба метода дают описание модели.
Оба метода применимы на практике.
Но системный подход сейчас сильнее продвигается, все стандарты переделаны под него, так что реально — выбора ни у Вас ни у меня нет. Только его применять.
DrPass
04.08.2017 02:05Все эти пункты очень хорошо измеряются и могут легко быть проконтролированы.
А тут другая проблема сразу же возникает. Как поставить адекватные значения целей? На сколько должен сократиться склад, чтобы считать задачу успешной? На сколько должно увеличиться количество заказов, обрабатываемых одним офис-менеджером? Насколько меньше должно стать неликвидов? И т.д. Что измерять, обычно понятно, если руководство хоть какие-то книги по управлению предприятием читало. А вот в каких попугаях, уже вопрос.surVrus
04.08.2017 10:10Все верно. Для этого все и разделяется по уровням. Инженеры читают одни книжки — им свои цели описываем. шефы — иные книжки наверное читают, что не факт. Ну им иначе пишем. Вместо одного огромного документа пишем 7 малых, каждый для своего уровня. Кстати, если никто и ничего не читал. То сначала делаем стандарты организации (СТО) для всех процессов. Это несложно, если базировать их на готовых стандартах, а не придумывать самим. Тогда получаем стандарт процесса 3-5 страниц, включая обложку. Коротко, просто, практично можно в виде комиксов или картинок, схем. На картинке только один аспект, только 5-9 элементов, только очень короткая часть процесса. И опять же, по аддитивной логике. И по типовым шаблонам. Пример из жизни: сделали систему управления качеством для фирмы, которая производит полимербетон. Все СТО, плюс таблицы и отчеты за год работы собрали в одну систему. В сумме около 100 отчетов и 15-17 СТО. С анализом, обоснованием и т.п. Использовали G Suite, плюс надстройки для схем и планирования. Делали 2 человека, в сумме около 80 нормочасов на всю. работу.
msin
04.08.2017 17:50Не нужно ставить значения, их можно взять только с потолка.
Нужно сравнивать с текущим состоянием предприятия (на момент перед внедрением).
У меня есть опыт внедрения (точнее, наблюдения за внедрением с т.з. работника предприятия).
Результаты внедрения видно невооруженным глазом:
1. Сокращение склада готовой продукции в 2 раза (сумма в рублях)
2. Сокращение производственного цикла в 4 раза с месяца (официальный срок выполнения заказа) до 5 раб. дней, при этом 2/3 делалось за 3 дня.
3. С выпуском продукции так хорошо не получилось по внешним обстоятельствам… дело было в 2008 году и начавшийся кризис привёл к падению спроса в ~3 разаDrPass
05.08.2017 21:09Нужно сравнивать с текущим состоянием предприятия (на момент перед внедрением).
А без адекватных целей это так себе проект. Если бы внедрение ERP ничего не стоило, можно было бы сказать, что это наверняка хорошо, и любое улучшение показателей означает успех. Но в реальности проект по внедрению практически всегда очень дорогой, и чтобы он был рентабельным, улучшения показателей тоже должны быть значительными.
У вас, вот, например, весьма нехарактерный случай. Если ERP позволила уменьшить склад в 2 раза, а производственный цикл в 4 раза, то даже страшно представить, насколько неэффективно работало предприятие до обАСУчивания. Обычно так не бывает. Улучшение параметров на 20-30% — это отличный показатель.msin
05.08.2017 22:46На любом случайно выбранном предприятии всегда жуткий бардак.
И как правило под ERP понимается некая автоматизация… и как правило в результате текущий бардак просто автоматизируется. Смысла от такой автоматизации нет.
Забудьте про ERP, на предприятии внедряется новая модель управления, для этого никакого ПО не нужно, если работники будут бегать с блокнотами, а вечером переносить все в Excel, то никакой разницы практически не будет. Ну хлопотно, да, но работать будет так же.
Кратное сокращение производственного цикла, как правило идёт со значительным ростом производительности — это уже превосходный результат. Я утверждаю, что это достигается только новыми подходами в управлении. А программное обеспечение это просто вспомогательный инструмент, не более. Excel + Access (97 года, ага) с доработкой напильником дадут практически все то же самое (80%), что и самая дорогая система.
Для справки — почитайте про результаты внедрения SAP. Это реально бесценная ERP, прайс-листа нет в принципе :-).DrPass
06.08.2017 01:16Да честно говоря, мой опыт скорее про обратное говорит. У большинства предприятий какие-то сложившиеся (и отлаженные годами) процессы всегда есть. Их нет в совсем уж запущенных случаях — или трепыхающийся динозавр времен СССР, или болото с жуткой текучкой кадров. Поэтому оно обычно там работает, где-то как-то оптимизировалось инициативными сотрудниками, и в целом вполне жизнеспособно. Лезть туда с радикальными изменениями процессов зачастую непродуктивно. Сопротивление персонала, положенное на неполное понимание со стороны руководства — и ваш проект завален. Чаще всего лучше как раз начинать с «автоматизацией бардака», сиречь, улучшением текущих процессов — автоматизацией составления отчетов, устранения ручной обработки данных, замена бумажек на электронные документы и т.д. И плюс новые фенечки, которые приносят осязаемую пользу: «Вот тут вы будете видеть неликвиды», «Вот тут можно будет посчитать финрезультат в разрезе каждого специалиста по продажам», «Вот тут можно автоматически блокировать заказы от клиентов с просроченной дебиторкой» и т.д.
Да, видел и трагикомичные случаи, которые как раз под «жуткий бардак» подходят. Например, завод, который производил аэрозоли, и на нём ни бухгалтерия, ни производственники не знали наличие товаров на складе. У них даже 1С была, но они не утруждали себя фиксацией приемки и выдачи на производство. Но в таких случаях новую модель управления не внедряют, там помогает только выжигание напалмом.msin
06.08.2017 10:49Поясню про бардак — это не полный хаос, конечно же нет.
Это локальные оптимизации в каждом подразделении, которые руководители и работники делают по своему пониманию логики работы.
В теории систем есть понятие контринтуитивности. Каждый делает то, что вроде бы должно улучшать работу, а целом получается бардак. Учет при этом весь ведётся.
И пока вы не сломаете текущую систему — ничего не получится. Надо ломать старую и внедрять новую. С преодолением сопротивления сотрудников и руководителей, потому что они не будут понимать — для чего так и почему не вот так. Очень часто владелец (генеральный) сам оказывается не готов изменяться (в первую очередь в образе мышления), тогда внедрение оканчивается неудачей и ничего не меняется…
Вот пара ресурсов с которых начинается новое понимание работы производства:
О здравом смысле и системном мышлении
О вариабельности и зависимости процессовsurVrus
06.08.2017 19:18Все верно. Но есть и иной подход.
Да, на любом предприятии есть набор процессов, которые так или иначе криво или не очень реализованы.
Смотрим на эти процессы, как га модель системы в одном аспекте.
Строим эту модель очень простым способом: все НЕОБХОДИМЫЕ процессы просто соединяем на схеме последовательно. Модель из теории надежности. Последовательная система. Элементы модели — только функции (действия). Получаем парсингом (семантическим анализом?) из use-case. Эта модель показывает, суть работы: при поломке любого процесса вся система выходит из строя.
Результат: названия всех функций на предприятии, без которых оно не может работать.
Далее анализируем уровень развития каждого элемента. Метод: взвешенный экспертный анализ. По трем параметрам каждый элемент: время — качество — деньги. Ничего нового, параметры из треугольника проекта. Находим наихудший элемент. Их будет несколько, потому, что параметра 3. Получим точное определение «бутылочного горлышка». Обычно оно и так известно на предприятии. Просто о нем не говорят…
Далее внедряем стандарты процессов именно для этих элементов. Там приколов масса, но можно сделать так, чтобы люди сами помогали. И да, внедрение возможно ТОЛЬКО через построение параллельной цепочки элементов. В имеющихся элементах менять ничего нельзя! По сути, дублируем часть функций. Самый прикол: можно даже старые методы использовать. Пока никаких MRP. Например, это часть процессов Закупки.
Далее расширяем границы системы внедрения, пока не станут близкими по очертаниям к стандартному модулю Закупки из системы MRP. Будет несколько больше элементов, чем в начале, ну и фиг с ними. Опять, все стандартизируем и типизируем. Опять же на основе любимых ISO и иных стандартов. Ну и психолог нам в помощь! Люди все-таки работают на местах, куда же без психологии.
Уже можно ставить почти ВСЕ модули MRP. Обычно, Закупки, Продажи, Склад, Финансы, Учет, какой-то центральный модуль. В разных системах немного по-разному, но разобраться несложно. Только то, что удобно и не будет проблем с инсталляцией потом. И да, лучше всего сразу все в «облаке». И да, все сопли насчет безопасности идут лесом. Не всегда, но почти в 70% случаев системы безопасности в облаке построены не в пример лучше, чем на предприятии. Это отдельная песня, тема целой статьи.
Но запускаем только Закупки. Там, где все стандартизировали. Всегда помним: «Первый шаг должен быть наиболее ЭФФЕКТНЫМ». Не путайте с эффективным! Это разные слова. Вот проект по внедрению MRP и закончен. Все.
Далее — следующий проект. Расширение функционала ИМЕЮЩЕЙСЯ системы MRP. Звучит совсем по-иному, иные риски и иная логика работы. Все пусть делают местные сами, по Вашим шаблонам, по Вашим стандартам. Главное: 70% времени и сил пусть Заказчик в проекте сам и тратит. По накатанной колее все летит со свистом. Опять же, последовательность внедрения — по наихудшим элементам в первую очередь.
И всегда помним о стандартах процессов: Вы их даете, Вы их адаптируете, чтобы все процессы Клиента выполнялись по таким типовыми процессам. Если нет такого процесса в наборе стандартных процессов — значит плохо искали! Не бывает таких вариантов! Никогда.
Когда процесс заработал — его можно автоматизировать.
Внедрение MRP — это именно стандартизация и отработка процессов на базе ИТ систем. Логика работы процессов работы в ИТ системах уже построена, она оптимальная. Это и есть те кубики конструктора, из которых строим систему для Клиента.
Не наоборот! Неважно, как привык Клиент делать. Не важно, как построены процессы на его предприятии. Все равно это будет часть стандартного набора процессов из уже годами отработанных. Вопрос корректного соответствия типовых процессов и процессов у Клиента.
А для этого надо знать типовые процессы бизнеса ЛУЧШЕ, чем Клиент. А с этим всегда дым и чад… Для того стандарты и публикуют. В них — отражение лучших практик в этой отрасли. Или хотя бы основы для подхода к проблеме.Gryphon88
06.08.2017 21:14А что стандарты говорят с точки зрения процессов про информирование/оповещение/логирование? Бутылочное горлышко может быть не только из-за объективных производственных причин, но и из-за того, что, грубо говоря, бумажка слишком долго ждёт подписи.
surVrus
07.08.2017 10:56А это отдельная подсистема. В модели GERAM две основные подсистемы. Типа производственная и обслуживающая. И они связаны весьма интересно, не иерархически. Смотрите тут (хотя текст не полный, но в приложениях почти все есть): https://www.iso.org/obp/ui/#iso:std:iso:15704:ed-1:v1:en
surVrus
07.08.2017 11:20Корректнее говорить о «событии». Некое событие возникает и обрабатывается в системе. Оно может (!) порождать бумажки и проходить через людей. Может не порождать бумажки (1 метод оптимизации). Можно исключить людей (2 метод оптимизации). А можно исключить сам процесс, порождающий или требующий бумажку. Сделать его частью иного процесса. И бумажка — это самое простое.
Одно из решений: стандарт процесса описывает время реакции в 24 часа на событие (например). Если триггер (утвердить или нет) — то автоматическое утверждение, если нет замечаний в течении 24 часов. Успел, не успел — по-фигу. Жестоко, но работает прекрасно. Так у нас договор, кстати, построен. Это один из немногих пунктов договора с Заказчиком. Если решение в выборе вариантов, то тоже установлено время принятия решения. К 18:00 решение принимается и все. Если не выбран оптимальный вариант через лицо принимающее решения, то автоматически выбирается один из предложенных вариантов. Метод выбора: случайный выбор. И да, уже доказано, что при принятии сложных решений в ситуации неполной, неточно и несвоевременной информации случайный выбор из нескольких более-менее равнозначных вариантов не хуже, чем оптимальный с какой-то точки зрения.
Технически и организационно внедрить такие алгоритмы работы несложно. Не в виде идеи! Даже не пытайтесь рассказывать такие идеи Заказчику. А просто в виде регламента, как само собой разумеется. Важен уровень проработки и обоснования такого метода. Проработка во всех аспектах: и юридическом, и финансовом, и организационном.
pebble Автор
04.08.2017 08:23Отличные цели, если брать в применении к п.2 статьи!
Но если рассматривать в части взаимоотношений с консалтингом (а именно об этом речь в разделе про консалт, откуда была использована цитата) и отражения этих целей в договоре — я сомневаюсь, что внедренцы согласятся подписать документ в таком виде. Потому что внедрение ИС (ответственность консалта) далеко не единственная составляющая, необходимая для реализации бизнес-целей. Есть куча аспектов, начиная от мастер-данных, регламентов и заканчивая трудовой дисциплиной на предприятии, которые непосредственно влияют на возможность достижения указанных Вами целей, но не находятся зоне ответственности консалта.
Но если на предприятии имеются такие четкие цели, причем с конкретным значением, это говорит о том, что уже был проведен полный аудит и анализ бизнес-процессов (см. первый раздел статьи), есть понимание, какие процессы и каким образом нужно изменить, какой результат ожидается от этого получить.
А значит результат этого аудита (схемы to be, математические формулы для расчета того или иного параметра и т.д.), могут использоваться как ТЗ для проекта по внедрению ERP-системы.
Тогда цель для договора с консалтингом – разворачивание ERP-системы в соответствии с ТЗ.surVrus
04.08.2017 10:48Все верно. Но Вы снова думаете и анализируете в классическом методе.
Консалтинг — это зло для любого проекта. Как нечто, проведенное на предприятии, как некая деятельность на предприятии сделанная один раз. А вот как систематическое постоянное обучения — может быть.
Отражение целей в договоре реализуется при системном подходе тоже очень просто. У нас договор — это 2-4 страницы. Очень простой, ясный и короткий. Его суть — main document, а не полный свод всех правил и взаимоотношений. Самое главное там, что все согласны с: мы делаем — они платят, всегда будут изменения во всех документах, все документы только в электронном виде — бумажные только «копия оригинального электронного документа», время реакции Сторон на любой документ — 24 часа, если нет реакции на документ — он автоматически считается утвержденным, и права собственности на результаты работ: не оплачено — права не переданы, ага и еще алгоритм прекращения проекта. Цели — в отдельном документе, с параметризацией. Впрочем, все в отдельных документах. И оплата строго по графику и по задачам. Выполнено задание — сразу же оплачено (если устраивает). Если не устраивает — реакция и изменения. Совсем работа не устраивает — разошлись. Риски с обеих сторон оценены, и минимизированы. По сути каждая задачка в рамках проекта — отдельный smart contract с системой микроплатежей, иногда на биткойнах. Ой, а у нас бухгалтерия не знает, как платить в электронном виде или что такое биткойн… Вот Вам СТО, как это делать. С проводками и юридическим обоснованием. Люди глупы и верят только в то, что хотят верить. Поэтому, если сделать им СТО — то они сначала всегда скажут, что там все не так. Через 2-3 дня они его изменят и поправят так, как должно быть. Выкинут затраты на кофе секретарю, исправят две точки и три запятых.И очень довольные все подпишут. Пока иначе не было ни разу. Все описано у Норткота Сирилла Паркинсона еще в 1960 году.
Куча иных аспектов всегда есть на предприятии. Поэтому внедрение ERP делается с полной стандартизацией всех бизнес-процессов. Все бизнес-процессы предприятия доводятся до уровня описания в типовом СТО. Обычно они примитивные и легко укладываются в уже известные модули. Например: была рецептура краски. По ней делают партию в цеху. Но в реальности некоторых компонентов для каждой партии идет немного иное количество, иногда больше загустителя. Было реализовано классическим методом: рецептура и документ, который показывает отклонения от рецептуры для конкретной партии. Плюс документы по расходу материалов со склада в производство. Что порождало изменения проводок в учете. Решение из стандарта IEC 61512: есть мастер-рецептура. В ней отражены теоретические расходы материалов. На основании мастер-рецептуры генерируется рецептура партии. В ней отражены фактические расходы материалов. Генерация идет автоматически по данным дозирования материала в партии, в момент производства. Бухгалтерия видит только рецептуру конкретной партии, причем все компоненты закодированы (еще и безопасность отработана). До мастер-рецептуры они не имеют доступа. Результат: количество событий и документов уменьшилось в 2 раза, бухгалтерия очень довольна (все идет по факту и вовремя), время учета партии сократилось на 30%.
Так изменения при внедрении (по сути, внедрения типового процесса) изменили процесс на предприятии. Причем все только помогали, потому что ленивые и хотят делать как проще. Чего мы им и дали. Я не шутил, когда писал, что все УЖЕ известно и многократно оптимизировано и описано в стандартах и best practice. И легально купить все стандарты стоит всегда дешевле, чем платить консультантам. И качество выше. Бери и делай. А если работник говорит, что в стандарте не оптимально? Именно для его варианта работы оптимальнее иначе, вот расчет и обоснование? Так это же прелестно! Тогда такой работник берет и сам переделывает стандарт так, как лучше. А делает он это опять же стандартным методом. Принцип — всегда используем изменения для реализации проекта. А не ищем стабильности и неизменности.
surVrus
04.08.2017 10:57Тогда цель для договора с консалтингом – разворачивание ERP-системы в соответствии с ТЗ.
Тоже верно. Только не с ТЗ! А в соответствии с действиями и документами проекта. Или просто в соответствии с проектной документацией. SRS — только часть такой документации. Всегда помним — не один документ определяет логику внедрения. А именно комплект документов! Отвяжитесь вы от этого несчастного ТЗ… Все это уже неактуально. Да, назвать документ можно так, как привык Клиент. Типа это ТЗ!!! А по сути — это комплект документов. И часто не надо утверждать чего-то там у шефа. Работаем параллельно на 5 уровнях. И главное — добиться только правильных контактов, чтобы реакция была на любое событие не более 12-24 часов. И ТОЛЬКО документы. Кстати, все беседы — тоже записываются и подписываются ЭЦП. И это тоже документ проекта, в форме аудиозаписи. Технически все это очень просто, так что можно не экономить.
И да, прежде всего приходится делать стандарты для себя, для Исполнителей проекта. Если их нет — то проект тоже можно внедрить. Если конкретный человек и будет таким стандартом. Метафора у Брукса, хирургическая бригада. Но только малые и быстрые проекты! Даже не пытайтесь делать так, если предприятие не дозрело до таких методов. Риски очень высокие.
surVrus
04.08.2017 00:22Благо дарю за ответ!
Тут вопрос именно методологии. Прежде всего, насчет документов. По системному подходу документы должны быть «атомизированы». То есть краткие и ограниченные. По моему опыту — не более 3-5 страниц (в эквиваленте А4). Принцип «гипертекстового знания». Пример про цели. Описание целей внедрения в Карте проекта — 2-3 предложения максимум.
Нюанс системного подхода: цель всегда указана для конкретного пользователя, только с его точки зрения, только в одном аспекте. Целей может быть 5-9. С разных точек зрения (аспект по ISO 81346).
А теперь самое сложное, потому, что совсем иная логика в системном (холистическом) подходе:
1. Одно описание цели всегда неполное, неточное, противоречивое иным целям. Даже не стремимся к уточнению!
2. Только все вместе цели дают приемлемое описание цели создания системы. Принцип аддитивной логики. Аналогия: 10 мудрецов описывают слона на ощупь в темной комнате.
3. Иерархия целей всегда многомерная. В разных аспектах — своя иерархия. Аналогия: обычно, иерархия целей строится в плоскости. А тут — многомерная структура, в объеме. Поэтому в одной системе координат одна цель — часть другой. А в иной системе координат — одна из целей вообще не существует. Целостное представление дает только суммарная, многомерная картинка.
4. Цели сформулируйте в виде существительных. Отдельно — в виде глаголов. Существительное — объект. Глагол — процесс. Никогда не совмещайте оба варианта.
5. Формулировка изначально не для понимания человеком. Изначально и всегда ориентируемся на информационную систему.
6. Более корректно принципы формулировки целей описаны в методологии LFA (Логико-структурный подход). И еще в НЛП, ищите «правила хорошо сформулированной цели».
Как бы Вы не сформулировали цели — всегда описание целей будет неполным, противоречивым и неточным! Но это не мешает работать и делать проект.
Принцип методологии реального проекта — как использовать постоянные изменения для работы проекта. Поэтому все документы проекта всегда меняются.
Кстати именно поэтому они и делаются короткими и всегда есть main document по ISO 11005 для определенной части проекта. Обычно — для каждого объекта есть такой документ. Обычно в виде списка документов, которые связаны с этим объектом.
Получаем для каждого элемента проекта есть только один документ. А в нем — список связанных документов. Не приложения к документу! А именно все отдельно.
Пример.
Классический подход: документ требования к системе (Д1). Один документ, в начале — оглавление. К нему 10 приложений со схемами или таблицами. 30-50 страниц
Системный подход: требования к системе — главный документ. В нем только типа «оглавление» из Д1 со ссылками на остальные документы. Отдельно — функциональные требования. Это документ Д2. На него есть ссылка в Д1. Но он СОВЕРШЕННО отдельный и независимый документ. Нефункциональные требования — документ Д3. Все то же самое. И так для КАЖДОГО документа, включая все бывшие приложения. Все эти документы связаны по метаинформации в репозитории документов проекта. Для чего так: Заказчику надо показать требования для экономистов. Это отдельный документ. Бери и работай. На остальные требования — не влияет. Для технологов — свой документ. И так для каждого заинтересованного лица. Свой взгляд, своя точка зрения. Свой аспект. И только все вместе — дают полный комплект требований к системе.А насколько проще все согласовать… Не надо переделывать все ТЗ. Очень просто разграничить доступ. Ну и так далее. Это не я все придумал! Я только вольно, криво и косо пересказал одну часть стандарта ISO по технической документации.
Могу дать доступ до своей электронной библиотеки, там все это есть более подробно и со стандартами. Библиотека на G suite организована, поэтому пришлите свой адрес на Гугл аккаунте gmail, и я тогда дам доступ к сайту. Доступ всегда бесплатный, но ограничен, потому, что там куча стандартов. А они типа не open source… Опаньки… Мой адрес vb@in-genium.in.
В заключение, немного целей системы ERP. Аспекты по ISO 81346, основные (= и -), дополнительные (финансовый #F и номер проекта #P для нумерации ).
Аспект функции (=):
Цели:
=F.001 Долгосрочный план. Показатель достижения цели (параметр): логический (да/нет)
=F.002 Краткосрочный план.Показатель достижения цели: логический (да/нет)
=F.003 План продукции. Показатель достижения цели: логический (да/нет)
Аспект финансовый (#F).
Цели:
#F.001 Транзакция продажи. Параметр: продолжительность. Значение: 0,1 нормочаса.
#F.002 Транзакция продажи. Параметр: затраты на осуществление. Значение: 100 рублей.
#F.003 Транзакция продажи. Параметр: количество за 1 месяц. Значение: 20 000
#F.004 Транзакция продажи. Сложность. Значение: низкая. Тип: выбор из списка «низкая» «средняя» " высокая". Метод оценки: СТО #P396=AF&BPQ001. Код документа я использовал реальный, на основе ISO 61355.
#F.005 Административные затраты. Параметр: сумма за 1 месяц. Значение: -20% Метод оценки: СТО #P396=AF&BPQ002.
Аспект продуктовый (продукт — сама система ERP).(-)
-P.001 Количество лицензий. Параметр: количество. Значение: 10
Все, надоело писать цели. Реально интеграция системы ERP по стандарту IEC 62264 может быть на 7 уровнях. Что-то типа как в модели OSI для инета. Все уровни прописаны, что где, как и когда происходит. Например,
Level 4 defines the business-related activities needed to manage a manufacturing organization.
Manufacturing-related activities include establishing the basic plant schedule (such as material use, delivery and shipping), determining inventory levels and making sure that materials are delivered on time to the right place for production.
То есть документ: #P396=AF.004&BEC001 Цели внедрения ERP будет содержать цели только для шефов отделов. И там не будет целей для уровня 5.
А для владельцев фирмы будут цели, структурированные и описанные для уровня 5. Что на этом уровне — тоже все прописано в стандарте. Получается, что в идеале будут 6-7 документов о целях внедрения системы ERP. Каждый получит только специалист с определенного уровня. И каждый документ описывает ВСЕ цели внедрения системы. Но только с точки зрения того, кому он адресован (соответствует номеру уровня) и не содержит ненужных деталей. ЦЕЛОСТЬ системы целей увидеть невозможно, и такая задача даже не ставится. То есть никакой «декомпозиции» целей, никакой «полноты, непротиворечивости» и т. п. нет и даже такая задача для ПРОЕКТА В ЦЕЛОСТИ не ставится.
Да, есть иерархия целей, да, может быть их «декомпозиция» — но только в каком-то одном аспекте. Один аспект — один документ.
Ага, и документ — это не «бумажка». А просто «обособленная часть информации». Документы для 5-6 уровня будут очень короткими. В идеале — 5-6 уровень это один абзац. Шефы это любят. А на уровне 1 — сотни, если не тысячи документов, по одному на каждый процесс.
Как все это организовать, соединять, следить? Несложно, это все тоже описано в тех же стандартах ISO IEC. По промышленным проектам — все реализовано в ePlan.
Для всего остального хватает G Suite. С технической точки зрения, для составления полной технической документации для строительства небольшого завода нужно немного времени, если применять новые методы системного подхода. Вся документация для такого проекта, вплоть до детальных списков с ценами всех элементов (до шурупа…), со всеми схемами для исполнителей, на 3 языках, делается за 1-2 дня. Если уже есть готовая библиотека типовых элементов!
Что касается проектов ИТ, или научных проектов, то все проще.
Например, мы вдвоем ведем одновременно сейчас 6 проектов:
Производство чистящих средств.
Производство краски.
Переработка промышленных отходов.
Функциональные продукты из пророщенного зерна.
Моделирование жилищного кооператива (фонда?)
Развитие сети MLM
Ну и успеваем делать методологию для ведения таких проектов. Это типа еще целый проект.
Это не потому, что мы типа крутые… Это просто такая методология, такой инструмент. Мы пока владеем им довольно посредственно. Да, с 2008 года мир сильно изменился. И да, я сам офигевал, когда читал книги по UML RUP PM и совершенно ничего не мог понять. Полная ахинея и заумь. А реально — совсем иной подход, холистический, целостный. И очень простой. Расширение классического подхода на иной логике и иной методологии.
И, кстати, про институты и про обучения. Когда я понял, что половину жизни потратил на изучение старых, кривых и косых методов — то немного разозлился на себя и на учителей. А теперь, вижу, что ни в России, ни тут в Польше ничего в обучении не поменялось. И учат точно такому же отстою. Все те же методы на основе редукционизма, нет обучения на основе системного (холистического) подхода. И тогда мне стало совсем фигово: вся эта кодла инженеров, ученых, манагаров, программастов после институтов годны только как кассиры в магазин. Приходится ПОЛНОСТЬЮ переучивать. И 50% времени — это выбивание их головы того мусора, что туда заложили в институтах. Реально — специалисты очень востребованы. Бабла платят кучу, работа — интересная. Но просто люди не понимают друг друга. Разная логика на уровне архетипов и самих основ сознания! Прикол: у некоторых людей перестройка логики при смене подходов на холистический приводит иногда просто к потере сознания. Отключка на 2-3 минуты и полная амнезия ближайших 5-10 минут разговора.
Так что все совсем не так, как мы думали… Все гораздо ЛУЧШЕ!
trdm
04.08.2017 12:25Составить перечень необходимой функциональности к новой системе.
Давно пора сделать онлайн конструкторы требований к учетной системе, где просто галочками отмечаешь что именно в данный момент тебе нужно. Пробежался по требованиям, проставил галки, распечатал экспортировал в нужный формат и приложил к договору или коммерческому приложению или к ТЗ.
Еще лучше если имеющиеся ИС забить туда с проставление галок что они могут и со стоимостью владения. Так специалист сможет определиться какая ИС ему подходит. А с производителей брать абонентку за каждый их продукт. :) Целая бизнес идея :)
На мой неискушенный взгляд каждый раз пытаться формулировать эти требования — ненужный геморрой.
Для составления такой БД можно пробежаться по форумам с разделами "ERP и учетные системы" или "Разработка информационных систем" — эти темы там хорошо обсосаны и расписаны. Или просто обратиться к профессиональным автоматизаторам.surVrus
04.08.2017 16:41Прелестно!
Это и есть один из стандартов процесса внедрения. Открою один секрет: ВСЕ ERP а также ИС сделаны по определенным моделям и стандартам ISO IEC IEEE. И буржуи просто не понимают, что вы от них хотите? Нафига вообще говорить и спрашивать о каких-то требованиях??? Для них — это нонсенс!
А делает ли ваша система то и это? Конечно делает, это же есть в стандарте. Зачем спрашивать? Если написано ERP — значит система реализует планирование (P) ресурсов ® на уровне группы предприятий (холдинга) (E). МОДЕЛЬ такого планирования описана в стандарте. В чем прикол, зачем спрашиваете?
Именно так они и воспринимают «манагаров» Заказчика. Потом понимают, что никто про стандарты не слышал и не читал их. И на это можно неплохо заработать… Ну тут сразу консультанты появляются… Все просто.
Да примитивно там все до невозможности! Поэтому нет смысла делать такие спецификации SRS. Просто переписывать стандарт туда IEC 62264? Зачем? Дешевле купить готовый перевод и не заморачиваться.
Не понятно что там написано? А это уже отдельная песня… В этом случае ни ТЗ (будь это слово трижды проклято в программировании), ни договора не помогут.
Внедрение, работа и практическое использование информационных систем ВСЕГДА построено на системном подходе. А 99% предприятий и руководителей в России пользуются в работе классическим подходом. Аналогия: классический подход — это черчение детали на листе бумаги в двух измерениях. Системный подход: разработка детали, через компьютерное моделирование ее изготовления, в трехмерном пространстве. Лист бумаги и карандаш — и система типа SolidWorks. Можно из SolidWorks получить чертеж на бумаге? Можно! Но это будет только 1% от возможностей системы. И чертеж нафиг не нужен! Потому, что все равно деталь будут печатать на 3D принтере.
Вот такая аналогия родилась… Так точно все и в системе ERP! «А можно накладную заполнять снизу вверх?» — да, можно. Но нафига это нужно? Даже накладные не нужны в новой системе. Вот в чем прикол! И да, это элементарно стыкуется с ПБУ и бухучетом. И да, я это много раз делал в России и в Европе. И да, ВСЕ вопросы бухгалтеров, налоговых инспекторов, проверяющих всех рангов, аудиторов решаются моментально. И да, все строго по методологии бухучета, действующему законодательству и обычаям делового оборота. Только одно требование к получателю информации есть: умение читать и зачатки разума. Все остальное обосновано на всех возможных уровнях. Поэтому вариант только один — учить матчасть в виде стандартов. Все равно применять придется. Так или иначе, рано или поздно.
Alozar
Слова, которые должны быть выбиты в камне!
Не счесть сколько внедрений, а иногда и компаний целиком, погорело от банального непонимания зачем оно надо.
pebble Автор
Кто-то в компании всегда понимает, зачем это надо. Только стесняется это озвучить вслух.