Pull to refresh

Comments 26

Сформулировать цель проекта и донести ее до всех представителей бизнеса, кто будет причастен к проекту. Вот только не надо обтекаемых формулировок типа «повышение эффективности деятельности предприятия за счет внедрения ERP»

Слова, которые должны быть выбиты в камне!
Не счесть сколько внедрений, а иногда и компаний целиком, погорело от банального непонимания зачем оно надо.
Кто-то в компании всегда понимает, зачем это надо. Только стесняется это озвучить вслух.
Прекрасно! Благодарю за информацию!
Мне довелось быть с обеих сторон разных проектов. В том числе нескольких внедрений информационных систем.
Не пишу 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 минимум), а всех, кто говорит про ТЗ — отправляйте в пешее эротическое путешествие.
Получил две статьи по цене одной :)
А вы не хотели бы осветить работу со стандартами более широко, возможно в виде статьи? Тема интересная, особенно в свете ваших слов «Потому, что с 2008 года во всем мире ВСЕ процессы (в том числе и абсолютно все бизнес-процессы) построены по готовым стандартам.»

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

И тем не менее гугление по вашему стандарту IEC 61512 выдает именно ГОСТ Р МЭК 61512-1-2016, который создан на базе IEC 61512-1:1997
Благо дарю за ответ!
Уже пишу статьи. Будет не одна, а скорее всего много. Материл есть, надо причесать и некоторые части перевести с польского и английского.
Да, везде указывают, что цель должна быть измеряема. Но вот досада, я до сих пор не умею формулировать короткие, ясные и измеримые цели. Либо коротко и ясно, но из формулировки не понятна измеримость,
либо с описанием необходимых ограничений и целевых параметров, но это уже выливается в отдельный документ и больше похоже на требования к системе, чем на цель.
Поэтому была бы благодарна, если Вы сможете привести, корректный по вашему мнению, пример цели при внедрении именно ERP-системы. Пример про «Время одной продажи = Х минут» не считаю подходящим — слишком однобокая формулировка для системы, поддерживающей большое количество БП.
UFO just landed and posted this here
Цель — существительное (продукт).
«Ресурс заменяем на сырье». То, что на входе предприятия. Причина: слово «ресурс» обозначает что-то иное, особенно в Управлении проектами. Может быть путаница. Используем стандартное определение (словарь) для производства на основе периодических процессов (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
Вот тогда можно измерить и проконтролировать.
И еще для каждого нужно указать метод измерения. Например СТО…
Извините, совсем забыл.
Цели у Вас msin указаны и сформулированы совершенно правильно!
Просто Вы используете одну методологи. (классический метод).
Я использую системный подход (холистический метод).
Оба метода дают описание модели.
Оба метода применимы на практике.
Но системный подход сейчас сильнее продвигается, все стандарты переделаны под него, так что реально — выбора ни у Вас ни у меня нет. Только его применять.
Все эти пункты очень хорошо измеряются и могут легко быть проконтролированы.

А тут другая проблема сразу же возникает. Как поставить адекватные значения целей? На сколько должен сократиться склад, чтобы считать задачу успешной? На сколько должно увеличиться количество заказов, обрабатываемых одним офис-менеджером? Насколько меньше должно стать неликвидов? И т.д. Что измерять, обычно понятно, если руководство хоть какие-то книги по управлению предприятием читало. А вот в каких попугаях, уже вопрос.
Все верно. Для этого все и разделяется по уровням. Инженеры читают одни книжки — им свои цели описываем. шефы — иные книжки наверное читают, что не факт. Ну им иначе пишем. Вместо одного огромного документа пишем 7 малых, каждый для своего уровня. Кстати, если никто и ничего не читал. То сначала делаем стандарты организации (СТО) для всех процессов. Это несложно, если базировать их на готовых стандартах, а не придумывать самим. Тогда получаем стандарт процесса 3-5 страниц, включая обложку. Коротко, просто, практично можно в виде комиксов или картинок, схем. На картинке только один аспект, только 5-9 элементов, только очень короткая часть процесса. И опять же, по аддитивной логике. И по типовым шаблонам. Пример из жизни: сделали систему управления качеством для фирмы, которая производит полимербетон. Все СТО, плюс таблицы и отчеты за год работы собрали в одну систему. В сумме около 100 отчетов и 15-17 СТО. С анализом, обоснованием и т.п. Использовали G Suite, плюс надстройки для схем и планирования. Делали 2 человека, в сумме около 80 нормочасов на всю. работу.
UFO just landed and posted this here
Нужно сравнивать с текущим состоянием предприятия (на момент перед внедрением).

А без адекватных целей это так себе проект. Если бы внедрение ERP ничего не стоило, можно было бы сказать, что это наверняка хорошо, и любое улучшение показателей означает успех. Но в реальности проект по внедрению практически всегда очень дорогой, и чтобы он был рентабельным, улучшения показателей тоже должны быть значительными.
У вас, вот, например, весьма нехарактерный случай. Если ERP позволила уменьшить склад в 2 раза, а производственный цикл в 4 раза, то даже страшно представить, насколько неэффективно работало предприятие до обАСУчивания. Обычно так не бывает. Улучшение параметров на 20-30% — это отличный показатель.
UFO just landed and posted this here
Да честно говоря, мой опыт скорее про обратное говорит. У большинства предприятий какие-то сложившиеся (и отлаженные годами) процессы всегда есть. Их нет в совсем уж запущенных случаях — или трепыхающийся динозавр времен СССР, или болото с жуткой текучкой кадров. Поэтому оно обычно там работает, где-то как-то оптимизировалось инициативными сотрудниками, и в целом вполне жизнеспособно. Лезть туда с радикальными изменениями процессов зачастую непродуктивно. Сопротивление персонала, положенное на неполное понимание со стороны руководства — и ваш проект завален. Чаще всего лучше как раз начинать с «автоматизацией бардака», сиречь, улучшением текущих процессов — автоматизацией составления отчетов, устранения ручной обработки данных, замена бумажек на электронные документы и т.д. И плюс новые фенечки, которые приносят осязаемую пользу: «Вот тут вы будете видеть неликвиды», «Вот тут можно будет посчитать финрезультат в разрезе каждого специалиста по продажам», «Вот тут можно автоматически блокировать заказы от клиентов с просроченной дебиторкой» и т.д.
Да, видел и трагикомичные случаи, которые как раз под «жуткий бардак» подходят. Например, завод, который производил аэрозоли, и на нём ни бухгалтерия, ни производственники не знали наличие товаров на складе. У них даже 1С была, но они не утруждали себя фиксацией приемки и выдачи на производство. Но в таких случаях новую модель управления не внедряют, там помогает только выжигание напалмом.
UFO just landed and posted this here
Все верно. Но есть и иной подход.
Да, на любом предприятии есть набор процессов, которые так или иначе криво или не очень реализованы.
Смотрим на эти процессы, как га модель системы в одном аспекте.
Строим эту модель очень простым способом: все НЕОБХОДИМЫЕ процессы просто соединяем на схеме последовательно. Модель из теории надежности. Последовательная система. Элементы модели — только функции (действия). Получаем парсингом (семантическим анализом?) из use-case. Эта модель показывает, суть работы: при поломке любого процесса вся система выходит из строя.
Результат: названия всех функций на предприятии, без которых оно не может работать.
Далее анализируем уровень развития каждого элемента. Метод: взвешенный экспертный анализ. По трем параметрам каждый элемент: время — качество — деньги. Ничего нового, параметры из треугольника проекта. Находим наихудший элемент. Их будет несколько, потому, что параметра 3. Получим точное определение «бутылочного горлышка». Обычно оно и так известно на предприятии. Просто о нем не говорят…
Далее внедряем стандарты процессов именно для этих элементов. Там приколов масса, но можно сделать так, чтобы люди сами помогали. И да, внедрение возможно ТОЛЬКО через построение параллельной цепочки элементов. В имеющихся элементах менять ничего нельзя! По сути, дублируем часть функций. Самый прикол: можно даже старые методы использовать. Пока никаких MRP. Например, это часть процессов Закупки.
Далее расширяем границы системы внедрения, пока не станут близкими по очертаниям к стандартному модулю Закупки из системы MRP. Будет несколько больше элементов, чем в начале, ну и фиг с ними. Опять, все стандартизируем и типизируем. Опять же на основе любимых ISO и иных стандартов. Ну и психолог нам в помощь! Люди все-таки работают на местах, куда же без психологии.
Уже можно ставить почти ВСЕ модули MRP. Обычно, Закупки, Продажи, Склад, Финансы, Учет, какой-то центральный модуль. В разных системах немного по-разному, но разобраться несложно. Только то, что удобно и не будет проблем с инсталляцией потом. И да, лучше всего сразу все в «облаке». И да, все сопли насчет безопасности идут лесом. Не всегда, но почти в 70% случаев системы безопасности в облаке построены не в пример лучше, чем на предприятии. Это отдельная песня, тема целой статьи.
Но запускаем только Закупки. Там, где все стандартизировали. Всегда помним: «Первый шаг должен быть наиболее ЭФФЕКТНЫМ». Не путайте с эффективным! Это разные слова. Вот проект по внедрению MRP и закончен. Все.
Далее — следующий проект. Расширение функционала ИМЕЮЩЕЙСЯ системы MRP. Звучит совсем по-иному, иные риски и иная логика работы. Все пусть делают местные сами, по Вашим шаблонам, по Вашим стандартам. Главное: 70% времени и сил пусть Заказчик в проекте сам и тратит. По накатанной колее все летит со свистом. Опять же, последовательность внедрения — по наихудшим элементам в первую очередь.
И всегда помним о стандартах процессов: Вы их даете, Вы их адаптируете, чтобы все процессы Клиента выполнялись по таким типовыми процессам. Если нет такого процесса в наборе стандартных процессов — значит плохо искали! Не бывает таких вариантов! Никогда.
Когда процесс заработал — его можно автоматизировать.
Внедрение MRP — это именно стандартизация и отработка процессов на базе ИТ систем. Логика работы процессов работы в ИТ системах уже построена, она оптимальная. Это и есть те кубики конструктора, из которых строим систему для Клиента.
Не наоборот! Неважно, как привык Клиент делать. Не важно, как построены процессы на его предприятии. Все равно это будет часть стандартного набора процессов из уже годами отработанных. Вопрос корректного соответствия типовых процессов и процессов у Клиента.
А для этого надо знать типовые процессы бизнеса ЛУЧШЕ, чем Клиент. А с этим всегда дым и чад… Для того стандарты и публикуют. В них — отражение лучших практик в этой отрасли. Или хотя бы основы для подхода к проблеме.
А что стандарты говорят с точки зрения процессов про информирование/оповещение/логирование? Бутылочное горлышко может быть не только из-за объективных производственных причин, но и из-за того, что, грубо говоря, бумажка слишком долго ждёт подписи.
А это отдельная подсистема. В модели GERAM две основные подсистемы. Типа производственная и обслуживающая. И они связаны весьма интересно, не иерархически. Смотрите тут (хотя текст не полный, но в приложениях почти все есть): https://www.iso.org/obp/ui/#iso:std:iso:15704:ed-1:v1:en
Корректнее говорить о «событии». Некое событие возникает и обрабатывается в системе. Оно может (!) порождать бумажки и проходить через людей. Может не порождать бумажки (1 метод оптимизации). Можно исключить людей (2 метод оптимизации). А можно исключить сам процесс, порождающий или требующий бумажку. Сделать его частью иного процесса. И бумажка — это самое простое.
Одно из решений: стандарт процесса описывает время реакции в 24 часа на событие (например). Если триггер (утвердить или нет) — то автоматическое утверждение, если нет замечаний в течении 24 часов. Успел, не успел — по-фигу. Жестоко, но работает прекрасно. Так у нас договор, кстати, построен. Это один из немногих пунктов договора с Заказчиком. Если решение в выборе вариантов, то тоже установлено время принятия решения. К 18:00 решение принимается и все. Если не выбран оптимальный вариант через лицо принимающее решения, то автоматически выбирается один из предложенных вариантов. Метод выбора: случайный выбор. И да, уже доказано, что при принятии сложных решений в ситуации неполной, неточно и несвоевременной информации случайный выбор из нескольких более-менее равнозначных вариантов не хуже, чем оптимальный с какой-то точки зрения.
Технически и организационно внедрить такие алгоритмы работы несложно. Не в виде идеи! Даже не пытайтесь рассказывать такие идеи Заказчику. А просто в виде регламента, как само собой разумеется. Важен уровень проработки и обоснования такого метода. Проработка во всех аспектах: и юридическом, и финансовом, и организационном.
Отличные цели, если брать в применении к п.2 статьи!
Но если рассматривать в части взаимоотношений с консалтингом (а именно об этом речь в разделе про консалт, откуда была использована цитата) и отражения этих целей в договоре — я сомневаюсь, что внедренцы согласятся подписать документ в таком виде. Потому что внедрение ИС (ответственность консалта) далеко не единственная составляющая, необходимая для реализации бизнес-целей. Есть куча аспектов, начиная от мастер-данных, регламентов и заканчивая трудовой дисциплиной на предприятии, которые непосредственно влияют на возможность достижения указанных Вами целей, но не находятся зоне ответственности консалта.

Но если на предприятии имеются такие четкие цели, причем с конкретным значением, это говорит о том, что уже был проведен полный аудит и анализ бизнес-процессов (см. первый раздел статьи), есть понимание, какие процессы и каким образом нужно изменить, какой результат ожидается от этого получить.
А значит результат этого аудита (схемы to be, математические формулы для расчета того или иного параметра и т.д.), могут использоваться как ТЗ для проекта по внедрению ERP-системы.
Тогда цель для договора с консалтингом – разворачивание ERP-системы в соответствии с ТЗ.
Все верно. Но Вы снова думаете и анализируете в классическом методе.
Консалтинг — это зло для любого проекта. Как нечто, проведенное на предприятии, как некая деятельность на предприятии сделанная один раз. А вот как систематическое постоянное обучения — может быть.
Отражение целей в договоре реализуется при системном подходе тоже очень просто. У нас договор — это 2-4 страницы. Очень простой, ясный и короткий. Его суть — main document, а не полный свод всех правил и взаимоотношений. Самое главное там, что все согласны с: мы делаем — они платят, всегда будут изменения во всех документах, все документы только в электронном виде — бумажные только «копия оригинального электронного документа», время реакции Сторон на любой документ — 24 часа, если нет реакции на документ — он автоматически считается утвержденным, и права собственности на результаты работ: не оплачено — права не переданы, ага и еще алгоритм прекращения проекта. Цели — в отдельном документе, с параметризацией. Впрочем, все в отдельных документах. И оплата строго по графику и по задачам. Выполнено задание — сразу же оплачено (если устраивает). Если не устраивает — реакция и изменения. Совсем работа не устраивает — разошлись. Риски с обеих сторон оценены, и минимизированы. По сути каждая задачка в рамках проекта — отдельный smart contract с системой микроплатежей, иногда на биткойнах. Ой, а у нас бухгалтерия не знает, как платить в электронном виде или что такое биткойн… Вот Вам СТО, как это делать. С проводками и юридическим обоснованием. Люди глупы и верят только в то, что хотят верить. Поэтому, если сделать им СТО — то они сначала всегда скажут, что там все не так. Через 2-3 дня они его изменят и поправят так, как должно быть. Выкинут затраты на кофе секретарю, исправят две точки и три запятых.И очень довольные все подпишут. Пока иначе не было ни разу. Все описано у Норткота Сирилла Паркинсона еще в 1960 году.
Куча иных аспектов всегда есть на предприятии. Поэтому внедрение ERP делается с полной стандартизацией всех бизнес-процессов. Все бизнес-процессы предприятия доводятся до уровня описания в типовом СТО. Обычно они примитивные и легко укладываются в уже известные модули. Например: была рецептура краски. По ней делают партию в цеху. Но в реальности некоторых компонентов для каждой партии идет немного иное количество, иногда больше загустителя. Было реализовано классическим методом: рецептура и документ, который показывает отклонения от рецептуры для конкретной партии. Плюс документы по расходу материалов со склада в производство. Что порождало изменения проводок в учете. Решение из стандарта IEC 61512: есть мастер-рецептура. В ней отражены теоретические расходы материалов. На основании мастер-рецептуры генерируется рецептура партии. В ней отражены фактические расходы материалов. Генерация идет автоматически по данным дозирования материала в партии, в момент производства. Бухгалтерия видит только рецептуру конкретной партии, причем все компоненты закодированы (еще и безопасность отработана). До мастер-рецептуры они не имеют доступа. Результат: количество событий и документов уменьшилось в 2 раза, бухгалтерия очень довольна (все идет по факту и вовремя), время учета партии сократилось на 30%.
Так изменения при внедрении (по сути, внедрения типового процесса) изменили процесс на предприятии. Причем все только помогали, потому что ленивые и хотят делать как проще. Чего мы им и дали. Я не шутил, когда писал, что все УЖЕ известно и многократно оптимизировано и описано в стандартах и best practice. И легально купить все стандарты стоит всегда дешевле, чем платить консультантам. И качество выше. Бери и делай. А если работник говорит, что в стандарте не оптимально? Именно для его варианта работы оптимальнее иначе, вот расчет и обоснование? Так это же прелестно! Тогда такой работник берет и сам переделывает стандарт так, как лучше. А делает он это опять же стандартным методом. Принцип — всегда используем изменения для реализации проекта. А не ищем стабильности и неизменности.
Тогда цель для договора с консалтингом – разворачивание ERP-системы в соответствии с ТЗ.
Тоже верно. Только не с ТЗ! А в соответствии с действиями и документами проекта. Или просто в соответствии с проектной документацией. SRS — только часть такой документации. Всегда помним — не один документ определяет логику внедрения. А именно комплект документов! Отвяжитесь вы от этого несчастного ТЗ… Все это уже неактуально. Да, назвать документ можно так, как привык Клиент. Типа это ТЗ!!! А по сути — это комплект документов. И часто не надо утверждать чего-то там у шефа. Работаем параллельно на 5 уровнях. И главное — добиться только правильных контактов, чтобы реакция была на любое событие не более 12-24 часов. И ТОЛЬКО документы. Кстати, все беседы — тоже записываются и подписываются ЭЦП. И это тоже документ проекта, в форме аудиозаписи. Технически все это очень просто, так что можно не экономить.
И да, прежде всего приходится делать стандарты для себя, для Исполнителей проекта. Если их нет — то проект тоже можно внедрить. Если конкретный человек и будет таким стандартом. Метафора у Брукса, хирургическая бригада. Но только малые и быстрые проекты! Даже не пытайтесь делать так, если предприятие не дозрело до таких методов. Риски очень высокие.
Благо дарю за ответ!
Тут вопрос именно методологии. Прежде всего, насчет документов. По системному подходу документы должны быть «атомизированы». То есть краткие и ограниченные. По моему опыту — не более 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 минут разговора.
Так что все совсем не так, как мы думали… Все гораздо ЛУЧШЕ!
Составить перечень необходимой функциональности к новой системе.

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

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

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

Именно так они и воспринимают «манагаров» Заказчика. Потом понимают, что никто про стандарты не слышал и не читал их. И на это можно неплохо заработать… Ну тут сразу консультанты появляются… Все просто.
Да примитивно там все до невозможности! Поэтому нет смысла делать такие спецификации SRS. Просто переписывать стандарт туда IEC 62264? Зачем? Дешевле купить готовый перевод и не заморачиваться.
Не понятно что там написано? А это уже отдельная песня… В этом случае ни ТЗ (будь это слово трижды проклято в программировании), ни договора не помогут.
Внедрение, работа и практическое использование информационных систем ВСЕГДА построено на системном подходе. А 99% предприятий и руководителей в России пользуются в работе классическим подходом. Аналогия: классический подход — это черчение детали на листе бумаги в двух измерениях. Системный подход: разработка детали, через компьютерное моделирование ее изготовления, в трехмерном пространстве. Лист бумаги и карандаш — и система типа SolidWorks. Можно из SolidWorks получить чертеж на бумаге? Можно! Но это будет только 1% от возможностей системы. И чертеж нафиг не нужен! Потому, что все равно деталь будут печатать на 3D принтере.
Вот такая аналогия родилась… Так точно все и в системе ERP! «А можно накладную заполнять снизу вверх?» — да, можно. Но нафига это нужно? Даже накладные не нужны в новой системе. Вот в чем прикол! И да, это элементарно стыкуется с ПБУ и бухучетом. И да, я это много раз делал в России и в Европе. И да, ВСЕ вопросы бухгалтеров, налоговых инспекторов, проверяющих всех рангов, аудиторов решаются моментально. И да, все строго по методологии бухучета, действующему законодательству и обычаям делового оборота. Только одно требование к получателю информации есть: умение читать и зачатки разума. Все остальное обосновано на всех возможных уровнях. Поэтому вариант только один — учить матчасть в виде стандартов. Все равно применять придется. Так или иначе, рано или поздно.
Sign up to leave a comment.

Articles