1. Полностью согласна, что диаграмма должна быть адаптирована под аудиторию.
Но, на мой взгляд, нужно не только определить аудиторию, но и оставить об этом информацию будущим пользователям диаграммы (на самой диаграмме, в сопроводительной документации).
2. Пожалуй, соглашусь с предложенной последовательностью построения (конечные цели — доступные ресурсы — промежуточные цели — процессы) для схем to be.
Для схем as is, думаю, нужно начинать с процессов, а уж к ним пристегивать цели и ресурсы: пользователи часто охотнее рассказывают о своей деятельности (то бишь о процессах), а вот цель этой деятельности не всегда могут сформулировать.
И одна из задач as is — определить процессы с неясными целями и, либо поставить им в соответствие какую-то полезную цель, либо «официально убить» эти процессы. Для as is, предложенная в статье последовательность будет способствовать «потере» процессов c неясными целями на схеме, но в реальной жизни они по прежнему будут исполняться.
Отличные цели, если брать в применении к п.2 статьи!
Но если рассматривать в части взаимоотношений с консалтингом (а именно об этом речь в разделе про консалт, откуда была использована цитата) и отражения этих целей в договоре — я сомневаюсь, что внедренцы согласятся подписать документ в таком виде. Потому что внедрение ИС (ответственность консалта) далеко не единственная составляющая, необходимая для реализации бизнес-целей. Есть куча аспектов, начиная от мастер-данных, регламентов и заканчивая трудовой дисциплиной на предприятии, которые непосредственно влияют на возможность достижения указанных Вами целей, но не находятся зоне ответственности консалта.
Но если на предприятии имеются такие четкие цели, причем с конкретным значением, это говорит о том, что уже был проведен полный аудит и анализ бизнес-процессов (см. первый раздел статьи), есть понимание, какие процессы и каким образом нужно изменить, какой результат ожидается от этого получить.
А значит результат этого аудита (схемы to be, математические формулы для расчета того или иного параметра и т.д.), могут использоваться как ТЗ для проекта по внедрению ERP-системы.
Тогда цель для договора с консалтингом – разворачивание ERP-системы в соответствии с ТЗ.
Да, везде указывают, что цель должна быть измеряема. Но вот досада, я до сих пор не умею формулировать короткие, ясные и измеримые цели. Либо коротко и ясно, но из формулировки не понятна измеримость,
либо с описанием необходимых ограничений и целевых параметров, но это уже выливается в отдельный документ и больше похоже на требования к системе, чем на цель.
Поэтому была бы благодарна, если Вы сможете привести, корректный по вашему мнению, пример цели при внедрении именно ERP-системы. Пример про «Время одной продажи = Х минут» не считаю подходящим — слишком однобокая формулировка для системы, поддерживающей большое количество БП.
Но, на мой взгляд, нужно не только определить аудиторию, но и оставить об этом информацию будущим пользователям диаграммы (на самой диаграмме, в сопроводительной документации).
2. Пожалуй, соглашусь с предложенной последовательностью построения (конечные цели — доступные ресурсы — промежуточные цели — процессы) для схем to be.
Для схем as is, думаю, нужно начинать с процессов, а уж к ним пристегивать цели и ресурсы: пользователи часто охотнее рассказывают о своей деятельности (то бишь о процессах), а вот цель этой деятельности не всегда могут сформулировать.
И одна из задач as is — определить процессы с неясными целями и, либо поставить им в соответствие какую-то полезную цель, либо «официально убить» эти процессы. Для as is, предложенная в статье последовательность будет способствовать «потере» процессов c неясными целями на схеме, но в реальной жизни они по прежнему будут исполняться.
Но если рассматривать в части взаимоотношений с консалтингом (а именно об этом речь в разделе про консалт, откуда была использована цитата) и отражения этих целей в договоре — я сомневаюсь, что внедренцы согласятся подписать документ в таком виде. Потому что внедрение ИС (ответственность консалта) далеко не единственная составляющая, необходимая для реализации бизнес-целей. Есть куча аспектов, начиная от мастер-данных, регламентов и заканчивая трудовой дисциплиной на предприятии, которые непосредственно влияют на возможность достижения указанных Вами целей, но не находятся зоне ответственности консалта.
Но если на предприятии имеются такие четкие цели, причем с конкретным значением, это говорит о том, что уже был проведен полный аудит и анализ бизнес-процессов (см. первый раздел статьи), есть понимание, какие процессы и каким образом нужно изменить, какой результат ожидается от этого получить.
А значит результат этого аудита (схемы to be, математические формулы для расчета того или иного параметра и т.д.), могут использоваться как ТЗ для проекта по внедрению ERP-системы.
Тогда цель для договора с консалтингом – разворачивание ERP-системы в соответствии с ТЗ.
либо с описанием необходимых ограничений и целевых параметров, но это уже выливается в отдельный документ и больше похоже на требования к системе, чем на цель.
Поэтому была бы благодарна, если Вы сможете привести, корректный по вашему мнению, пример цели при внедрении именно ERP-системы. Пример про «Время одной продажи = Х минут» не считаю подходящим — слишком однобокая формулировка для системы, поддерживающей большое количество БП.