Comments 64
UFO just landed and posted this here
Ну и к чему претензии? SAP не поставил вековые БП тяжмаша в коробке, или тяжмаш должен был из-за покупки лицензий изменить процессы сразу «как надо»? Или вообще не 6адо было ничего покупать, оставить как есть?
UFO just landed and posted this here
В треугольнике Заказчик-ERP-Консультант, последние вряд ли являются самым слабым звеном. Мы научились достаточно точно оценивать достаточность компетенции и ресурсов консалтинга в проекте. А вот вероятность того, что Заказчик или ИТ-система подведут сложно спрогнозировать и риски ошибок больше.
Как это IT-система может «непрогнозируемо» подвести?
Неправильно спроектированная, недоделанная — очень даже легко.
Архитектура заточена под один тип операций, а бизнесу нужен на самом деле другой.
Вы же понимаете, что это недопонимание ситуации или подрядчиком, или заказчиком. Если оба понимают функционал системы, «она» в этом треугольнике кого-то подведет вряд ли.
Исключения — неожиданные косяки со стороны вендора (если внедряется новый функционал, который раньше не реверсился участниками проекта, или при обновлениях).
Исключения — неожиданные косяки со стороны вендора (если внедряется новый функционал, который раньше не реверсился участниками проекта, или при обновлениях).
Честно говоря, не встречал такого интегратора, который бы обещал безболезненный переход. Если такие и есть, то в топку таких. Как правило, грамотный интегратор говорит, что изменение бизнес-процессов произойдет менее болезненно, если на то будет реальная управленческая воля Заказчика. Именно поэтому опытные интеграторы пытаются выяснить функционального заказчика, спонсора проекта и их полномочия ещё на этапе предпродажи.
Изменение бизнес-процессов под те, которые уже реализованы в типовой системе — это да, это один из критериев и факторов успешного проекта. Это изменение должно проводиться не потому, что так хочет подрядчик или ИТ-подразделение. Такое обоснование Заказчику не пройдет. Тут имеется ввиду, что в распространенной типовой системе эти бизнес-процессы уже настроены на основе лучших методологий и предыдущих проектов. Понятно, что типовую систему и сопровождать легче и эксплуатировать, но главное — что если бизнес-процессы у Заказчика в корне отличаются от функционала системы, то тут нужно внимательнее посмотреть:
1. Либо система выбрана в корне неверная
2. Либо пришла пора Заказчику повнимательнее присмотреться к своим бизнес-процессам ещё до внедрения системы.
Условный тяжмаш действительно поимеет чемодан без ручки, если отнесется к внедрению ERP-системы без должного внимания. Это одна из ключевых проблем таких проектов — интегратор должен ПОМОЧЬ Заказчику определиться с требованиями к ней. Помочь, но не выполнить за него. Вернее, интегратор может и требования к системе сформировать и реализовать их, но в таком случае эта внедренная система останется «ещё одним безумным проектом чеканутых айтишников»
Изменение бизнес-процессов под те, которые уже реализованы в типовой системе — это да, это один из критериев и факторов успешного проекта. Это изменение должно проводиться не потому, что так хочет подрядчик или ИТ-подразделение. Такое обоснование Заказчику не пройдет. Тут имеется ввиду, что в распространенной типовой системе эти бизнес-процессы уже настроены на основе лучших методологий и предыдущих проектов. Понятно, что типовую систему и сопровождать легче и эксплуатировать, но главное — что если бизнес-процессы у Заказчика в корне отличаются от функционала системы, то тут нужно внимательнее посмотреть:
1. Либо система выбрана в корне неверная
2. Либо пришла пора Заказчику повнимательнее присмотреться к своим бизнес-процессам ещё до внедрения системы.
Условный тяжмаш действительно поимеет чемодан без ручки, если отнесется к внедрению ERP-системы без должного внимания. Это одна из ключевых проблем таких проектов — интегратор должен ПОМОЧЬ Заказчику определиться с требованиями к ней. Помочь, но не выполнить за него. Вернее, интегратор может и требования к системе сформировать и реализовать их, но в таком случае эта внедренная система останется «ещё одним безумным проектом чеканутых айтишников»
UFO just landed and posted this here
Когда писали и внедряли ERP для себя — начали с описания и оптимизации существующих бизнес-процессов для каждого отдела и везде ходил генеральный директор, которого не пошлёшь подальше фразой «я тут работу работаю и мне некогда вашими игрушками заниматься» и уже на этом этапе смогли сэкономить большие суммы.
Правда, произошло это после срыва внедрения ERP интегратором (2 года и тысячи человекочасов по $50/час коту под хвост)
Правда, произошло это после срыва внедрения ERP интегратором (2 года и тысячи человекочасов по $50/час коту под хвост)
Трудно представить себе, чтобы кто-то из владельцев или топ-менеджеров крупного промышленного предприятия приобретал ERP-систему ради моды.
Какая наивная фраза:)
По поводу самого моделирования — мне кажется, нужно моделировать и как есть, и как должно быть, чтобы системному аналитику/консультанту было проще понять гэпы в бизнес-логике.
P.S. Никаких хороших слов не пишу про статью не потому, что я вредина, а только потому, что я не разбираюсь в этой сфере настолько хорошо, чтобы оценивать.
Да, в идеальной ситуации, когда есть время и ресурсы для моделирования идеально будет, если процессы будут описаны и «как есть» и «как будет». На моей практике такого не случалось никогда.
Вариант 1. Заказчик сообщает, что бизнес-процессы «как есть» его не устраивают. Они плохо документированы, плохо мониторятся и заказчик не видит ценности в том, чтобы описывать тот бардак, который его без всякого бумажного описания не устраивает. Заказчик в таком случае готов как можно быстрее перейти к обсуждению целевой модели, чтобы убедиться в том, что его пожелания, наболевшие вопросы нашли отражение в модели проектируемой системы.
Вариант 2. Предприятие с более-менее работающими бизнес-процессами. Как правило, уже есть ряд внедренных систем, системы живые, используемые, но уперлись в функциональные, технологические ограничения. Тогда да, есть вероятность того, что Заказчик в состоянии построить моделирование от ситуации «как есть». Тогда мне видится правильным именно брать существующие процессы и строить гап-анализ по ним.
Но на моей практике было всего одно предприятие, которое, как мне кажется, довольно уверенно говорило о актуальности существующей модели процессов. Но они отказались от модернизации существующей системы со словами«мы нашу нынешнюю систему пилили 10 лет. Только допилили и пока психологически не готовы начать процесс внедрения заново». От проекта отказались на самом первоначальном этапе.
Вариант 1. Заказчик сообщает, что бизнес-процессы «как есть» его не устраивают. Они плохо документированы, плохо мониторятся и заказчик не видит ценности в том, чтобы описывать тот бардак, который его без всякого бумажного описания не устраивает. Заказчик в таком случае готов как можно быстрее перейти к обсуждению целевой модели, чтобы убедиться в том, что его пожелания, наболевшие вопросы нашли отражение в модели проектируемой системы.
Вариант 2. Предприятие с более-менее работающими бизнес-процессами. Как правило, уже есть ряд внедренных систем, системы живые, используемые, но уперлись в функциональные, технологические ограничения. Тогда да, есть вероятность того, что Заказчик в состоянии построить моделирование от ситуации «как есть». Тогда мне видится правильным именно брать существующие процессы и строить гап-анализ по ним.
Но на моей практике было всего одно предприятие, которое, как мне кажется, довольно уверенно говорило о актуальности существующей модели процессов. Но они отказались от модернизации существующей системы со словами«мы нашу нынешнюю систему пилили 10 лет. Только допилили и пока психологически не готовы начать процесс внедрения заново». От проекта отказались на самом первоначальном этапе.
Ну на практике в большинстве случаев компании никакого описания ни реальных, ни целевых процессов не пишут.
Вариант 2 — полностью согласен.
Вариант 1 — теоретически я не против, просто моделирование желаемых процессов в таких случаях постоянно упирается в невозможность их реализовать (оказывается, что часть нужных данных некому вести, их нет или работники не готовы заполнять их на своем этапе, многие действия заранее не смогли предусмотреть или вспомнить при моделировании и т.д.). То есть, такая модель очень сильно отличается от того, что получится в результате. Но, опять же, это может быть специфика тех проектов, с которыми я работал.
Вариант 2 — полностью согласен.
Вариант 1 — теоретически я не против, просто моделирование желаемых процессов в таких случаях постоянно упирается в невозможность их реализовать (оказывается, что часть нужных данных некому вести, их нет или работники не готовы заполнять их на своем этапе, многие действия заранее не смогли предусмотреть или вспомнить при моделировании и т.д.). То есть, такая модель очень сильно отличается от того, что получится в результате. Но, опять же, это может быть специфика тех проектов, с которыми я работал.
Для того и предназначено описание бизнес-процессов, чтобы понять чего с точки зрения ресурсов не хватает. Понятно, что целевая модель описывается с определенным уровнем детализации и на этапе описания нет никакой уверенности, что описаны все значимые процессы. Но без этого описания не будет понятен объем проблемы.
По поводу того, что нет данных, некому их вести или неготовы заполнять — так это и есть положительный результат моделирования — выявленная проблема, в которой обозначена потребность бизнеса и выявлен недостаток ресурсов.
Моя практика тоже говорит о том, что в процессы, смоделированные на начальном этапе как правило, перестают смотреть сразу, после подписания ТЗ. Ну так это не от того, что этого делать не надо, а от того, что либо у Заказчика не хватает потенций следовать согласованным требованиям к системе, либо подрядчик оказался несколько некомпетентен.
А не моделировать процессы, это все равно, что не делать проект дома, мотивируя это тем, что рабочие все равно построят как бог на душу положит…
По поводу того, что нет данных, некому их вести или неготовы заполнять — так это и есть положительный результат моделирования — выявленная проблема, в которой обозначена потребность бизнеса и выявлен недостаток ресурсов.
Моя практика тоже говорит о том, что в процессы, смоделированные на начальном этапе как правило, перестают смотреть сразу, после подписания ТЗ. Ну так это не от того, что этого делать не надо, а от того, что либо у Заказчика не хватает потенций следовать согласованным требованиям к системе, либо подрядчик оказался несколько некомпетентен.
А не моделировать процессы, это все равно, что не делать проект дома, мотивируя это тем, что рабочие все равно построят как бог на душу положит…
Я не говорил, что их не нужно описывать. Просто так происходит.
Конечно. Только при модели «Как надо» это нельзя выяснить. Это можно понять, когда понятная разница между тем, как надо, и как есть (другой вопрос, нужно ли и то, и то формально моделировать в нотациях или это можно понять из устных обсуждений — но это понимание обязательно должно быть).
По поводу того, что нет данных, некому их вести или неготовы заполнять — так это и есть положительный результат моделирования — выявленная проблема, в которой обозначена потребность бизнеса и выявлен недостаток ресурсов.
Конечно. Только при модели «Как надо» это нельзя выяснить. Это можно понять, когда понятная разница между тем, как надо, и как есть (другой вопрос, нужно ли и то, и то формально моделировать в нотациях или это можно понять из устных обсуждений — но это понимание обязательно должно быть).
Трудно представить себе, чтобы кто-то из владельцев или топ-менеджеров крупного промышленного предприятия приобретал ERP-систему ради моды.
Это шутка такая?
Один из ключевых рисков на проектах — недостаточное внимание со стороны топ-менеджеров и/или собственников. Когда приобретают не ради моды, так себя не ведут.
Это я планировал написать в отдельной статье. Попытаюсь тезисно. Допустим, ген. директор действительно демонстрирует потребность в реализации какой-то системы. Но при этом он далеко не всегда является её функциональным заказчиком. А функциональный заказчик может выдвигать свои требования к системе, которые могут и не совпадать с целями, которые держит ген. дир. Или функциональных заказчиков много и они на своем уровне не могут собрать целостную картину целей. Допустим, гл. диспетчер хочет иметь в автоматизированной системе факт загрузки рабочих центров для более корректного оперативного планирования, а зав. производством не готов эту информацию предоставить (к примеру, по причине неактуальных норм на выполнение операций на станках). А зав. складом по каким-то причинам не хочет привести в актуальное состояние информацию о остатках на складах полуфабрикатов.
Вот и получается, что ген. дир. демонстрирует заинтересованность в проекте, тащит его, но упирается в сопротивление функциональных заказчиков по далеко не всегда объективным причинам.
Вот и получается, что ген. дир. демонстрирует заинтересованность в проекте, тащит его, но упирается в сопротивление функциональных заказчиков по далеко не всегда объективным причинам.
Сформулированные Бизнес-процессы служат основой не только для построения ИС, но и для формирования штатного расписания, написания регламентов, должностных инструкций и пр.
И если у завскладом в должностной инструкции написано — «отражать остатки», его сопротивление гасится административными методами.
И если у завскладом в должностной инструкции написано — «отражать остатки», его сопротивление гасится административными методами.
Именно. Это как раз та идея, которую я не смог продать на одном крупном проекте. Что смоделированные процессы «как будет» и реализованные в системе до этого, конечно же, согласованные управляющим комитетом проекта) влегкую могут стать и основой для должностных инструкций рядовых исполнителей и основой для всяческих регламентов и положений. А уж если туда прописать ещё и время на выполнение операций… Уууух что бы было. Но где-то не хватило у функциональных руководителей потенций, где-то — желания. То есть процессы есть, смоделированы, реализованы, на практике с небольшими отклонениями используются, но утверждать бизнес-процессы как регламентирующие документы не стали. От бумажных неподробных должностных инструкций не отказались.
Как Вы вообще и на каком основании можете говорить о "неоптимальности" тех бизнес-процессов, которые не ложатся в паттерн ERP систем, но при этом тянут компанию "десятки", с Ваших же слов, лет?
Такие процессы обходятся предприятию значительно дороже.
«Газпрому» это не важно, пока.
Коммерческие компании, работающие на конкурентном рынке, уже давно вынуждены минимизировать издержки. Не эффективных банально выдавят более низкой себестоимостью.
С другой стороны, некоторые «ERP-системы», таковыми не являются в полной мере: либо специализируются на конкретном виде бизнеса, либо разрабатываются дилетантами копипастой функционала. «Паттерн ERP систем» в этом случае вообще не имеет смысла.
«Газпрому» это не важно, пока.
Коммерческие компании, работающие на конкурентном рынке, уже давно вынуждены минимизировать издержки. Не эффективных банально выдавят более низкой себестоимостью.
С другой стороны, некоторые «ERP-системы», таковыми не являются в полной мере: либо специализируются на конкретном виде бизнеса, либо разрабатываются дилетантами копипастой функционала. «Паттерн ERP систем» в этом случае вообще не имеет смысла.
Наивно предполагать, что "оптимизированные" процессы обязательно вообще запустятся. Оптимизировать можно только с пониманием особенностей бизнеса, с анализом того, почему вообще устроено так, а не иначе, после долгого аудита и при участии всех заинтересованных лиц. Неосторожное внедрение ERP разрушило уже не одни не оптимальные, но эффективные процессы и привело к убыткам.
Наверно стоило добавить в предыдущий комментарий пару слов и про эффективных некомпетентных оптимизаторов.
И да вы правы, процесс запустятся только когда будет понятен и принят всеми участниками. По поим наблюдениям 2/3 работы пооптимизации устранению выявленных проблем, приходится на вовлечение/замену исполнителей.
И да вы правы, процесс запустятся только когда будет понятен и принят всеми участниками. По поим наблюдениям 2/3 работы по
Либо они запустятся (возможно, с применением кнута и пряника) либо они не оптимальны совсем. Вероятность того, что на этапе моделирования будут описаны как надо все 100% процессов — практически нулевая. Это верно. Но скелет должен быть правилен, реален, исполним. Все остальные процессы должны встраиваться в существующую систему.
Вообще, конечно, бизнес-процессы — вещь живая на предприятии и грешно думать, что вот мы сейчас один раз потщательнее смоделируем все и потом 10 лет ничего трогать не будем. Нет, как только ты закончил оптимизировать 1 процесс, ты увидел ещё 3, которые срочно надо оптимизировать. Такова ля ви…
Вообще, конечно, бизнес-процессы — вещь живая на предприятии и грешно думать, что вот мы сейчас один раз потщательнее смоделируем все и потом 10 лет ничего трогать не будем. Нет, как только ты закончил оптимизировать 1 процесс, ты увидел ещё 3, которые срочно надо оптимизировать. Такова ля ви…
А в чем противоречие? Процесс рабочий, но не оптимальный. такого разве не может быть?
Пример из практики. 1-й сотрудник предприятия вносит в старую систему данные по премированию сотрудников подразделения. Печатает итоговый документ. Подписывает бумажку у руководителя. Несет его сотруднику 2. Сотрудник 2 берет этот бумажный документ, открывает этот документ в системе и глазками, по линеечке, проверяет каждую строчку. После этого ставит волшебную галочку в системе и документ закрывается для редактирования. Данные уходят в расчет зарплаты. А при расчете зарплаты сотрудник 3 проверяет данные, введенные сотрудником 1 и может вернуть уже утвержденный документ сотруднику 1 на исправление. И пошел второй цикл. Рабочий процесс? Рабочий. Оптимальный? Нет. Причины? А потому что сотрудник 2 не доверяет сотруднику 1, считает, что после того, как руководитель подписал бумажку сотрудник 1 мог внести изменения в документ в системе. Ну и почему-то старая система не давала в должный момент запрета на редактирование этого документа сотруднику 1. А сотрудник 3 проверяет корректность начисления премии. Почему не делает этого сотрудник номер 2? Потому что у него нет знаний и данных для проверки расчета. Почему сотрудник 1 не отвечает за корректность введенных им данных? Да потому что квалификация не позволяет, ошибаются часто, а система не позволяет производить этот расчет автоматически. Итого: занято 3 сотрудника, ценность процесса — практически нулевая.
И такой процесс был реализован годами.
Пример из практики. 1-й сотрудник предприятия вносит в старую систему данные по премированию сотрудников подразделения. Печатает итоговый документ. Подписывает бумажку у руководителя. Несет его сотруднику 2. Сотрудник 2 берет этот бумажный документ, открывает этот документ в системе и глазками, по линеечке, проверяет каждую строчку. После этого ставит волшебную галочку в системе и документ закрывается для редактирования. Данные уходят в расчет зарплаты. А при расчете зарплаты сотрудник 3 проверяет данные, введенные сотрудником 1 и может вернуть уже утвержденный документ сотруднику 1 на исправление. И пошел второй цикл. Рабочий процесс? Рабочий. Оптимальный? Нет. Причины? А потому что сотрудник 2 не доверяет сотруднику 1, считает, что после того, как руководитель подписал бумажку сотрудник 1 мог внести изменения в документ в системе. Ну и почему-то старая система не давала в должный момент запрета на редактирование этого документа сотруднику 1. А сотрудник 3 проверяет корректность начисления премии. Почему не делает этого сотрудник номер 2? Потому что у него нет знаний и данных для проверки расчета. Почему сотрудник 1 не отвечает за корректность введенных им данных? Да потому что квалификация не позволяет, ошибаются часто, а система не позволяет производить этот расчет автоматически. Итого: занято 3 сотрудника, ценность процесса — практически нулевая.
И такой процесс был реализован годами.
Спасибо за пример.
В вашем примере первый сотрудник отвечает за сбор данных, второй за коммерцию, третий за отражение операций в учетной системе. В какой момент вы приняли решение что процесс неоптимальный, по каким критериям?
Критерий один: ценность операции и выход из бизнес-процесса.
1. Сотрудник1 производит обсчет премии на калькуляторе, прежде чем завести в систему. Это недостаток системы. У сотрудника1 выход из операции есть — документ, но его формирование можно оптимизировать.
2. Сотрудник2 просто перепроверяет сотрудника1. Ценности никакой не приносит, если бы система не позволяла менять данные. И значимого выхода из его операции нет.
Бумажка за подписью руководителя — это тоже атавизм, следствие недоверия данным в системе. В бизнес-процессе «как будет» этой бумажки и сотрудника2 быть не должно. Корректность данных — ответственность сотрудника1. Если человек бестолочь — надо его менять, а не нанимать контролера за ним.
3. Сотрудник3 проверяет данные и в случае возникновения расхождений возвращает на исправление сотруднику1. Сотрудник2, который и без того был занят работой, не несущей ценности, вынужден повторить ненужную проверку сотрудника1 ещё раз.
Это тоже ненужные операции.
1. Сотрудник1 производит обсчет премии на калькуляторе, прежде чем завести в систему. Это недостаток системы. У сотрудника1 выход из операции есть — документ, но его формирование можно оптимизировать.
2. Сотрудник2 просто перепроверяет сотрудника1. Ценности никакой не приносит, если бы система не позволяла менять данные. И значимого выхода из его операции нет.
Бумажка за подписью руководителя — это тоже атавизм, следствие недоверия данным в системе. В бизнес-процессе «как будет» этой бумажки и сотрудника2 быть не должно. Корректность данных — ответственность сотрудника1. Если человек бестолочь — надо его менять, а не нанимать контролера за ним.
3. Сотрудник3 проверяет данные и в случае возникновения расхождений возвращает на исправление сотруднику1. Сотрудник2, который и без того был занят работой, не несущей ценности, вынужден повторить ненужную проверку сотрудника1 ещё раз.
Это тоже ненужные операции.
Это если моделировать процесс, как поток работ: первый считает, второй и третий проверяют. Если смотреть на целевое назначение действий исполнителей, то это может быть «Сбор данных», «Согласование затрат» и «Ввод данных в учетную систему по факту отгрузки». Тогда эти работы нельзя ни по временной шкале совместить, ни по модели компетенций объеденить одному исполнителю, ни по ресурсам, рискам и т.п.
Даже в вашей модели 2-го и 3-го сотрудника с их компетенциями можно заменить роботами, поскольку они являются «Вахтерами» с фиксированной логикой действий. В результате себестоимость процесса снижается почти в 3 раза.
Да и «модель компетенций» должна строиться на основании модели процессов, а не наоборот. Если у процесса цель создать ценность.
Да и «модель компетенций» должна строиться на основании модели процессов, а не наоборот. Если у процесса цель создать ценность.
Извините за глупый вопрос, но как методически моделируются процессы, на каком этапе разработки и внедрения это происходит, кто с предприятия-заказчика участвует?
Элементарно.
По кругу: маркетинг, закупки/производство, продажи.
И обеспечивающие процессы (логистика, бухгалтерия, кадры ...).
Далее каждый процесс детализируется в зависимости от конкретного вида бизнеса.
С предприятия как минимум должен участвовать генеральный директор. Крайне желательно также вовлечь владельцев основных процессов.
По кругу: маркетинг, закупки/производство, продажи.
И обеспечивающие процессы (логистика, бухгалтерия, кадры ...).
Далее каждый процесс детализируется в зависимости от конкретного вида бизнеса.
С предприятия как минимум должен участвовать генеральный директор. Крайне желательно также вовлечь владельцев основных процессов.
Как это выглядит внешне? Сначала собираются бумажки, описывающие ответственность и перемещение мат.ценностей, а потом происходит что-то типа planning poker, строятся диаграммы Ганта, или что?
Как у меня на проектах, где много функциональных блоков.
Скелет процессов, как описано выше в комментарии практически 1: основные процессы, вспомогательные, обслуживающие. Основные: продажи, закупки, производство и т.д., но только те процессы, которые напрямую отвечают за получение прибыли предприятия. Потом, когда закончили основные — идут вспомогательные: логистика, склады и т.д. Потом уже обслуживающие: ИТ, бюжетирование, казначейство, бухучет и т.д.
Это очередность обследования. дальше в каждом процесс идет разбивка на подпроцессы с формированием выходов и входов каждого из них. Важно по окончании моделирования одного процесса иметь все его входы и выходы. Т.к. при обследовании второго процесса, зависимого от первого, вы всегда сможете проконтролировать: а все ли, что производит 1 процесс нашло отражение во втором? Или наоборот, а все ли, что ждут на старте второго процесса готов дать процесс первый?
Скелет процессов, как описано выше в комментарии практически 1: основные процессы, вспомогательные, обслуживающие. Основные: продажи, закупки, производство и т.д., но только те процессы, которые напрямую отвечают за получение прибыли предприятия. Потом, когда закончили основные — идут вспомогательные: логистика, склады и т.д. Потом уже обслуживающие: ИТ, бюжетирование, казначейство, бухучет и т.д.
Это очередность обследования. дальше в каждом процесс идет разбивка на подпроцессы с формированием выходов и входов каждого из них. Важно по окончании моделирования одного процесса иметь все его входы и выходы. Т.к. при обследовании второго процесса, зависимого от первого, вы всегда сможете проконтролировать: а все ли, что производит 1 процесс нашло отражение во втором? Или наоборот, а все ли, что ждут на старте второго процесса готов дать процесс первый?
Извините, но по-моему это не моделирование, а специфицирование. Как-то состыковать их и проверить исполнимость и скорость, а также сделать то же самое с новыми, чтобы убедиться, что получилось быстрее и менее затратно по персоналу и прочему? Я мыслю примитивно: если есть правила, то им нужно следовать. Проверяется ли, что не получится ли итальянская забастовка при полном соблюдении регламента?
Возможно вы мыслите «узко», в смысле не выше менеджера среднего звена, или по «функциональной» модели.
Регламенты позволяют описать взаимодействие максимум с соседними функциями/процессам. Общую картину по ним очень сложно собрать. Тем более если надо с ней в дальнейшем поработать, например оптимизировать.
Регламенты позволяют описать взаимодействие максимум с соседними функциями/процессам. Общую картину по ним очень сложно собрать. Тем более если надо с ней в дальнейшем поработать, например оптимизировать.
Приходит специально обученный человек, называется «бизнес-аналитик», в отдел, и говорит: расскажите, как вы работаете. Сотрудники рассказывают ему про какой-нибудь свой бизнес-процесс, иногда показывают, аналитик задает уточняющиеся вопросы до тех пор, пока ему не становится понятно. Когда становится понятно, рисует модель бизнес-процесса (например, модель по BPMN).
Так в каждом отделе предприятия, пока все нужные бизнес-процессы не будут описаны в моделях.
Бизнес-аналитик может работать и в штате, и у подрядчика.
По-хорошему, моделирование бизнес-процессов должно быть выполнено до автоматизации, и сами бизнес-процессы не должны меняться во время нее.
Так в каждом отделе предприятия, пока все нужные бизнес-процессы не будут описаны в моделях.
Бизнес-аналитик может работать и в штате, и у подрядчика.
По-хорошему, моделирование бизнес-процессов должно быть выполнено до автоматизации, и сами бизнес-процессы не должны меняться во время нее.
А как отличают варианты "положено по регламенту" и "на самом деле"?
То, что положено по регламенту, тоже моделируется.
Ты приходишь в отдел, наблюдаешь как проходит на самом деле, сравниваешь с регламентом, и либо сразу делаешь замечание, либо моделируешь «как есть».
Только зачем это?
В теории сначала моделируется «как есть», потом проектируется «как должно быть», и после этого под «должно» пишется регламент.
Ты приходишь в отдел, наблюдаешь как проходит на самом деле, сравниваешь с регламентом, и либо сразу делаешь замечание, либо моделируешь «как есть».
Только зачем это?
В теории сначала моделируется «как есть», потом проектируется «как должно быть», и после этого под «должно» пишется регламент.
Немного не так задал вопрос. Вот приходит чужой человек, которому нет оснований доверять, и начинает расспросы. В итоге может оказаться, что регламент, рассказ и фактическая деятельность соотносятся между собой довольно слабо. можете дать пару советов, как в таком клубке разобраться?
Идти к руководителю проекта с изложением ситуации и ждать, пока он разберется.
Могу научно объяснить, почему это единственный правильный и рабочий вариант, но думаю Вы можете поверить на слово:)
Могу научно объяснить, почему это единственный правильный и рабочий вариант, но думаю Вы можете поверить на слово:)
Кого Вы понимаете под руководителем проекта? На крупных проектах руководитель проекта несет политическую функцию и не в состоянии решить методологический вопрос. Разве что административно, не вдаваясь в детали.
Вопрос был скорее в том, как описывать тогда, когда все вольно или невольно врут.
Тут, ИМХО, нужно смотреть на уровень корпоративной культуры предприятия. Если она демократичная, то просто выносить все найденные несоответствия на руководителя функционального блока и коллективно обсуждать их.
Если культура административно-приказная — готовить протокол обследования, формализовывать разрывы, делать по каждому разрыву фикс решения. Я только не очень понял чем рассказ в комментарии выше отличается от фактической деятельности. Есть бумажный регламент. Есть рассказ ответственного сотрудника, по которому видно где есть несоответствия с формализованным документом.
Вопрос был скорее в том, как описывать тогда, когда все вольно или невольно врут.
Тут, ИМХО, нужно смотреть на уровень корпоративной культуры предприятия. Если она демократичная, то просто выносить все найденные несоответствия на руководителя функционального блока и коллективно обсуждать их.
Если культура административно-приказная — готовить протокол обследования, формализовывать разрывы, делать по каждому разрыву фикс решения. Я только не очень понял чем рассказ в комментарии выше отличается от фактической деятельности. Есть бумажный регламент. Есть рассказ ответственного сотрудника, по которому видно где есть несоответствия с формализованным документом.
Кого Вы понимаете под руководителем проекта?
Человека, который принимает решение о том, по какой версии бизнес-процессов нужно вести автоматизацию, если этих версий четыре (регламентированные; «как рассказали пользователи»; реальные, о которых никто не знает; те, которые могут получиться с учетом возможностей программного продукта) или больше.
Этот человек — не бизнес-аналитик (не тот, кто описывает эти процессы).
Вопрос был скорее в том, как описывать тогда, когда все вольно или невольно врут.
Как описывать — вопрос бизнес-аналитика.
А что описывать — вопрос руководителя проекта.
И ответ на него дается индивидуальный в каждой конкретной ситуации.
Аналитику нужно
1. Получить четкое задание на то, какие именно версии бизнес-процессов нужно смоделировать
2. Допустим, РП ставит задачу выяснить реальные бизнес-процессы, при условии что пользователи их честно не расскажут
3. Теперь аналитик в трудной ситуации, когда рассказы сотрудников заведомо ложные, и им нельзя верить. Что можно сделать:
I. Получить нужные административные ресурсы (быть уверенным, что ты имеешь право и возможность лезть в реальные БП и изучать их не со слов сотрудников)
II. Проверить данные в существующих базах и попробовать найти доказательства, что описанный бизнес-процесс не соблюдался
III. Сидеть в отделе и просто наблюдать за работой сотрудников вживую
и т.д. Но вообще такая работа со стороны внешнего IT-подрядчика не особо эффективна, это функции внутреннего аудита. Задача IT-подрядчика — согласовать бизнес-процесс, на который согласен заказчик.
то просто выносить все найденные несоответствия на руководителя функционального блока и коллективно обсуждать их.
Вынести можно то, что уже смоделировано!
Если у нас есть модели всех процессов (и реальных, и целевых, и т.д.) — задача по моделированию решена. Дальше начинается совсем другая сфера функций.
Человека, который принимает решение о том, по какой версии бизнес-процессов нужно вести автоматизацию, если этих версий четыре (регламентированные; «как рассказали пользователи»; реальные, о которых никто не знает; те, которые могут получиться с учетом возможностей программного продукта) или больше.
Если проект небольшой и руководитель проекта компетентен — то да. А если проект большой? Как, допустим, руководитель проекта (ИТ-директор допустим) должен указать производству согласовывать ли сменно-суточное задание со службой главного диспетчера или ограничиться контролем исполнения месячного плана? У РП в таком случае нет ни таких полномочий, ни таких функциональных знаний. Я думаю, что такие решения должны приниматься коллективно членами управляющего комитета.
Вынести можно то, что уже смоделировано!
Как это видится? Моделируем, допустим, процесс «как есть» на основании интервью и утвержденного регламента. Сотрудник говорит, что отправляет заключенный договор в производство для включения в план и только А уже производство при недостатке материалов формирует заявку на закупку. А регламент говорит, что заключенный договор должен сразу попадать в отдел закупок, когда ещё производство расчет потребностей не сделало. И что тогда моделировать? Оба варианта? А если расхождений сотни? Сколько версий процессов будет? Нет, фиксировать несоответствие и решать его надо сразу.
У РП в таком случае нет ни таких полномочий, ни таких функциональных знаний. Я думаю, что такие решения должны приниматься коллективно членами управляющего комитета.
У РП практически никогда нет (и не должно быть) полномочий по построению самих бизнес-процессов.
Я имел ввиду, что он должен принять решение, какие процессы нужно моделировать, если оказывается, что их версий несколько (например, если оказывается, что реальные отличаются от тех, которые рассказывают подразделения). Каждый лишний анализ гэпов увеличивает трудозатраты аналитика, но вопрос «анализировать ли их» не должен стоять перед аналитиком. Ему ставят задачу другие люди (а точнее, руководитель проекта; а с кем он в свою очередь ее согласует, это его дело).
И что тогда моделировать? Оба варианта? А если расхождений сотни? Сколько версий процессов будет? Нет, фиксировать несоответствие и решать его надо сразу.
Я в комментариях не делал разницы между «моделировать», «выяснять» и «описывать».
Если Вы об этом — согласен.
«Чужого» человека приводит руководитель и всех обязывает сотрудничать. Аудит может начать внезапную проверку соблюдения регламентов, с привлечением «стороннего специалиста».
Расхождения достаточно легко проявляются при анализе первичных документов за период, либо на стыках процессов перекрестной проверкой.
Расхождения достаточно легко проявляются при анализе первичных документов за период, либо на стыках процессов перекрестной проверкой.
С таким подходом реализовать проект сложно. В принципе, должно быть так, что «приходит человек, которому нет оснований не доверять». А ещё лучше, чтобы в результатах обследования был вовлечен топ-менеджмент. И тогда обследование — это повод для персонала конструктивно рассказать о том, что в текущих процессах не устраивает. Ибо низовой персонал очень часто носитель ключевой информации и лучше других может видеть где конкретно нужно вносить изменения.
В клубке не надо разбираться — запутаетесь. Нужно без особых ньюансов понять «как есть» и обсуждать «как хотелось бы». Я всегда в в предпроектном обследовании пытаюсь выстроить такой скелет:
1. Услышать как бизнес-процесс идет сейчас. От начальной операции до конечной. Если в обследовании принимает участие несколько человек, то очень важно проводить интервью структурно, а то беседа превращается быстро в обсуждение какого-либо одного наболевшего вопроса или в коллективный плач Ярославны с жалобами на начальство или другие подразделения.
2. После описания «как есть» укрупненно рассказать как это реализовано в предлагаемой системе сейчас. И вывести народ на разговор типа: «О! Круто! Нам как раз так надо» или «Не, это нам не подойдет, потому что...». И всегда добиваться, чтобы это «потому что» прозвучало.
3. Перечень озвученных «потому что» уже и есть перечень насущных проблем. Дополнить его ответами на вопрос «а что бы Вам ещё хотелось видеть в системе» — и вот они укрупненные требования к автоматизации.
С проектным обследованием примерно так же, но детализация процесса и разговор намного глубже.
В клубке не надо разбираться — запутаетесь. Нужно без особых ньюансов понять «как есть» и обсуждать «как хотелось бы». Я всегда в в предпроектном обследовании пытаюсь выстроить такой скелет:
1. Услышать как бизнес-процесс идет сейчас. От начальной операции до конечной. Если в обследовании принимает участие несколько человек, то очень важно проводить интервью структурно, а то беседа превращается быстро в обсуждение какого-либо одного наболевшего вопроса или в коллективный плач Ярославны с жалобами на начальство или другие подразделения.
2. После описания «как есть» укрупненно рассказать как это реализовано в предлагаемой системе сейчас. И вывести народ на разговор типа: «О! Круто! Нам как раз так надо» или «Не, это нам не подойдет, потому что...». И всегда добиваться, чтобы это «потому что» прозвучало.
3. Перечень озвученных «потому что» уже и есть перечень насущных проблем. Дополнить его ответами на вопрос «а что бы Вам ещё хотелось видеть в системе» — и вот они укрупненные требования к автоматизации.
С проектным обследованием примерно так же, но детализация процесса и разговор намного глубже.
А ещё лучше, чтобы в результатах обследования был вовлечен топ-менеджмент. И тогда обследование — это повод для персонала конструктивно рассказать о том, что в текущих процессах не устраивает. Ибо низовой персонал очень часто носитель ключевой информации и лучше других может видеть где конкретно нужно вносить изменения.
Мне что-то вспомнилась серия статей о цветах корпоративной культуры… Получается, что компании, которым действительно нужна переделка бизнес-процессов. не смогут сделать ни реалистичный анализ, ни воспринять внешнее изменение.
Почему? Не понял.
Вы про «красный цвет»? Ну да, там есть определенные сложности со сломом иерархии, но это не значит, что они неустранимы. Просто это будет несколько сложнее, чем в других случаях. Но я бы не сказал, что шансов нет
Вы про «красный цвет»? Ну да, там есть определенные сложности со сломом иерархии, но это не значит, что они неустранимы. Просто это будет несколько сложнее, чем в других случаях. Но я бы не сказал, что шансов нет
По оптимистичной оценке, не менее 60 процентов внедрений ERP завершаются или полным провалом (вообще не стартует система), или не достигаются большая часть ключевых целей проекта.
Ходила байка, что на Светлане в 80х, где процессоры выпускали, однажды выпуск годных изделий на неделю вырос с 10% до 30%, а потом снова упал.
Начали искать — с чего вдруг, оказалось, на неделю приходила студентка и писала диплом, а сборщицы решили, что это нормировщица, проверяет качество и по регламенту ли идут работы и начали выполнять всё как нужно.
Хотя может и врут.
Начали искать — с чего вдруг, оказалось, на неделю приходила студентка и писала диплом, а сборщицы решили, что это нормировщица, проверяет качество и по регламенту ли идут работы и начали выполнять всё как нужно.
Хотя может и врут.
Как-то противоречиво — вроде речь об автоматизации существующих процессов, но чуть ли не со старта предлагается процессы менять под систему.
Обычно частные предприятия строились по принципу «Слепила из того что было» по собственному видению модели. Когда до владельца доходит, что такое предприятие не эффективно, начинается принятие мер.
Автоматизация без наведения порядка в такой компании, только усугубит ее проблемы. Вот и приходится сначала перестраивать по ГОСТу, потом автоматизировать.
Автоматизация без наведения порядка в такой компании, только усугубит ее проблемы. Вот и приходится сначала перестраивать по ГОСТу, потом автоматизировать.
Утрированно: как Вы вытираете дома пыль? Поднимаете предмет, проводите тряпкой под ним, ставите обратно? Или увидев, что предмет стоит не на своем месте относите его на место правильное? Вы же вроде пыль вытирать собирались, а не расставлять предметы по местам.
Автоматизация существующих процессов — это автоматизация бардака, которая позволит быстрее принимать неправильные решения, и соответственно быстрее привести бизнес к печальному концу :)
Прастити (tm)
Прастити (tm)
Народ с интересом обсуждает тонкости внедрения, бизнес-процессы, влияющие факторы и т.д. А толку? Почему никто не смотрит шире?
Собственно место всех обсуждающих специалистов простое — выполнить некую функцию (и это не оптимизация бизнес-процессов) и затем рассказать более грамотным в бизнесе людям о проблемах заказчика. Всё. Далее, конечно, можно заниматься саморазвитием и считать, что вы на самом деле крутой бизнес-аналитик, но повторюсь — толку от этого = ноль.
Почему всё именно так? Потому что система более высокого уровня не предполагает качества своих подсистем. В результате заказчики делятся на тех, кто и без бинес-оптимизаторов всё сам сделает (спроектирует процессы, наймёт кого надо, укажет от какого забора копать и до какого времени), и на вторую категорию — большинство. Как наверное уже понятно, первая категория очень малочислена, но что это означает для бизнеса? А означает это одну очень простую вещь — для зарабатывания не надо всех этих бизнес-процессов и прочих оптимизаций. Повторюсь — не надо. Потому что заказчики из «большинства», даже если им всё сделать за них и преподнести на блюдечке с каёмочкой, потом обязательнопросрут спустят результаты в унитаз. Просто они по другому не умеют. Не потому что тупые, а в следствии обязанности существовать в той самой системе более высокого уровня.
Вот поэтому более грамотные в бизнесе люди знают, что таким заказчикам (то есть почти всем) нужно «что-то сделать», а потом перевести стрелки на самих заказчиков, благо сами заказчики для этого предоставляют все возможности.
Бизнес, по сути, очень простой — психологическая обработка клиента, подписание договора внедрения, выполнение неких ритуальных действий, а далее — главное. И главным является создание комплекса вины у заказчика. То есть он должен считать (и что важно — обоснованно), что именно он виноват. Ну и всё, проект можно записывать в успешные. Ведь виноватый заказчик не станет воевать с ситуацией, когда его же вину старательно заглаживает гораздо менее виноватый исполнитель.
Ну и чуть-чуть экономики. Ради чего это всё? Исключительно ради денег (если есть желающие описать альтруиста-интегратора — вэлкам, посмеёмся вместе). Но если деньги главное, а заказчики неспособные, то как можно в такой ситуации заработать на оптимизации бизнес-процессов? Ответ дан выше — сделать вид, что оптимизируете, а далее всё свалить (и небезосновательно) на заказчика. Ведь деньги-то получены, так почему бы не объявить проект успешным и не пойти к следующему заказчику? Хотя да, текущего бросать тоже нельзя, ведь он за поддержку будет платить. Так что бизнес-идея в реализации грамотных психологов (умеющих привить чувство вины даже тем, кто от рождения не чувствовал себя виноватым) реально приносит много-миллионные прибыли.
Ну а обсуждения из серии «почему у нас не получается внедрить качественно» — это не про данный бизнес. Надеюсь, что к данному моменту уже понятно почему. Вот и перестаньте напрягаться, просто осознайте важность денег и психологии. Заказчик чего-то хочет? Это прекрасно! Ведь это что-то можно продать за деньги! И не важно, что заказчик сам не определился, важнее другое — сам процесс продажи умных слов с очень высокой нормой прибыли за одно умное слово. Пока есть не определившиеся заказчики — бизнес будет процветать! Очень простая бизнес-идея. И очень древняя. Раньше алхимики королям мозги сношали, всяческие авантюристы приставали со своими прожектами открытия америки, а вот сегодня — консультанты. Но не того уровня, на котором вы привыкли находиться, а как раз те самые, которые отлично умеют в психологию. И да, они так же отлично понимают реальность, и что в ней главное — деньги. А не какие-то там бизнес-процессы.
Собственно место всех обсуждающих специалистов простое — выполнить некую функцию (и это не оптимизация бизнес-процессов) и затем рассказать более грамотным в бизнесе людям о проблемах заказчика. Всё. Далее, конечно, можно заниматься саморазвитием и считать, что вы на самом деле крутой бизнес-аналитик, но повторюсь — толку от этого = ноль.
Почему всё именно так? Потому что система более высокого уровня не предполагает качества своих подсистем. В результате заказчики делятся на тех, кто и без бинес-оптимизаторов всё сам сделает (спроектирует процессы, наймёт кого надо, укажет от какого забора копать и до какого времени), и на вторую категорию — большинство. Как наверное уже понятно, первая категория очень малочислена, но что это означает для бизнеса? А означает это одну очень простую вещь — для зарабатывания не надо всех этих бизнес-процессов и прочих оптимизаций. Повторюсь — не надо. Потому что заказчики из «большинства», даже если им всё сделать за них и преподнести на блюдечке с каёмочкой, потом обязательно
Вот поэтому более грамотные в бизнесе люди знают, что таким заказчикам (то есть почти всем) нужно «что-то сделать», а потом перевести стрелки на самих заказчиков, благо сами заказчики для этого предоставляют все возможности.
Бизнес, по сути, очень простой — психологическая обработка клиента, подписание договора внедрения, выполнение неких ритуальных действий, а далее — главное. И главным является создание комплекса вины у заказчика. То есть он должен считать (и что важно — обоснованно), что именно он виноват. Ну и всё, проект можно записывать в успешные. Ведь виноватый заказчик не станет воевать с ситуацией, когда его же вину старательно заглаживает гораздо менее виноватый исполнитель.
Ну и чуть-чуть экономики. Ради чего это всё? Исключительно ради денег (если есть желающие описать альтруиста-интегратора — вэлкам, посмеёмся вместе). Но если деньги главное, а заказчики неспособные, то как можно в такой ситуации заработать на оптимизации бизнес-процессов? Ответ дан выше — сделать вид, что оптимизируете, а далее всё свалить (и небезосновательно) на заказчика. Ведь деньги-то получены, так почему бы не объявить проект успешным и не пойти к следующему заказчику? Хотя да, текущего бросать тоже нельзя, ведь он за поддержку будет платить. Так что бизнес-идея в реализации грамотных психологов (умеющих привить чувство вины даже тем, кто от рождения не чувствовал себя виноватым) реально приносит много-миллионные прибыли.
Ну а обсуждения из серии «почему у нас не получается внедрить качественно» — это не про данный бизнес. Надеюсь, что к данному моменту уже понятно почему. Вот и перестаньте напрягаться, просто осознайте важность денег и психологии. Заказчик чего-то хочет? Это прекрасно! Ведь это что-то можно продать за деньги! И не важно, что заказчик сам не определился, важнее другое — сам процесс продажи умных слов с очень высокой нормой прибыли за одно умное слово. Пока есть не определившиеся заказчики — бизнес будет процветать! Очень простая бизнес-идея. И очень древняя. Раньше алхимики королям мозги сношали, всяческие авантюристы приставали со своими прожектами открытия америки, а вот сегодня — консультанты. Но не того уровня, на котором вы привыкли находиться, а как раз те самые, которые отлично умеют в психологию. И да, они так же отлично понимают реальность, и что в ней главное — деньги. А не какие-то там бизнес-процессы.
Основной закон эволюции, действующий со времен зарождения жизни — слабые не выживают. Так что «Санитары леса» всегда будут доить компании из 2-го списка до разорения.
«Бизнес-процессы» — один из инструментов, обеспечивающий прозрачность деятельности компании из 1-го списка для ее владельцев и сотрудников. Или для планирования изменений. Но пользуются им в основном высшее руководство, вполне возможно за пределами компании.
«Бизнес-процессы» — один из инструментов, обеспечивающий прозрачность деятельности компании из 1-го списка для ее владельцев и сотрудников. Или для планирования изменений. Но пользуются им в основном высшее руководство, вполне возможно за пределами компании.
Чувствуется, наболело.
Вы правы и неправы одновременно. Если заказчик из первой группы, то Вы же сами говорите, что он наймет кого-то на изменение бизнес-процессов. Но что такое изменение? Это как раз моделирование, их реализация и аудит процесса в эксплуатации. А какая в современном мире реализация бизнес-процессов может обойтись без автоматизации? Вот я как раз об этом и говорил: интегратор может взять на себя функцию моделирования, если у заказчика своих потенций нет. Ну и уж точно берет на себя функцию реализации и, частично, последующего аудита.
Что касается большинства. Я уже про это писал выше: если принести все заказчику «на блюдечке», то принести ему в таком случае можно разве что «чемодан без ручки». Это та ситуация, когда заказчик говорит: «не знаю как, но сделайте мне красиво» и если интегратор на такой заказ соглашается, то берет на себя все охрененные риски того, что невовлеченный заказчик получит в итоге результат его устраивающий и применимый в его бизнесе.
Как избежать комплекса вины у заказчика? Нет никаких инструментов кроме одного: всяческими доступными средствами держать заказчика вовлеченным в проект все 100% времени жизни проекта. 100% вовлеченным. Я понимаю, что это про то, что «лучше быть здоровым и богатым, чем бедным и больным», но иначе никак.
Вы правы и неправы одновременно. Если заказчик из первой группы, то Вы же сами говорите, что он наймет кого-то на изменение бизнес-процессов. Но что такое изменение? Это как раз моделирование, их реализация и аудит процесса в эксплуатации. А какая в современном мире реализация бизнес-процессов может обойтись без автоматизации? Вот я как раз об этом и говорил: интегратор может взять на себя функцию моделирования, если у заказчика своих потенций нет. Ну и уж точно берет на себя функцию реализации и, частично, последующего аудита.
Что касается большинства. Я уже про это писал выше: если принести все заказчику «на блюдечке», то принести ему в таком случае можно разве что «чемодан без ручки». Это та ситуация, когда заказчик говорит: «не знаю как, но сделайте мне красиво» и если интегратор на такой заказ соглашается, то берет на себя все охрененные риски того, что невовлеченный заказчик получит в итоге результат его устраивающий и применимый в его бизнесе.
Как избежать комплекса вины у заказчика? Нет никаких инструментов кроме одного: всяческими доступными средствами держать заказчика вовлеченным в проект все 100% времени жизни проекта. 100% вовлеченным. Я понимаю, что это про то, что «лучше быть здоровым и богатым, чем бедным и больным», но иначе никак.
Sign up to leave a comment.
Моделирование бизнес-процессов как часть проекта по внедрению ERP-системы