Комментарии 59
Все верно, но, зачастую системным мышлением обладают исключительно ИТ-специалисты, поэтому все-таки общий вид системы должен обязательно видеть ИТ-шник (например, IT директор или какой-нибудь архитектор).
На большом производстве каждый отдел будет пытаться растащить систему на свои Excel-таблицы. Чтобы заставить вводить данные, которые им не нужны, но нужны в других отделах — нужно сильно постараться. Все должно работать на общее благо.
Ну и нужно оценивать адекватность самих руководителей. Бывает, что желание есть, а знаний — никаких, хотят чтобы было все просто — вы внедренцы, вот и внедряйте, мы деньги заплатили и знать ничего не хотим… так тоже ничего не получится.
На большом производстве каждый отдел будет пытаться растащить систему на свои Excel-таблицы. Чтобы заставить вводить данные, которые им не нужны, но нужны в других отделах — нужно сильно постараться. Все должно работать на общее благо.
Ну и нужно оценивать адекватность самих руководителей. Бывает, что желание есть, а знаний — никаких, хотят чтобы было все просто — вы внедренцы, вот и внедряйте, мы деньги заплатили и знать ничего не хотим… так тоже ничего не получится.
Согласен. Создавал сам ERP систему для ритейла, работал напрямую с владельцем компании, но все главные идеи структуры данных, методы обработки придумывал сам по мере изучения бизнеса. Система не обычная по сравнению с существующими, но эффективная именно из-за того, что мне не задавали задание, а наоборот, я его создавал изучая бизнес со стороны. Если бы мне задавали задание, получилось бы тоже самое что у всех, кто на бизнес изнутри смотрит, а значит и смысла в новой системе не было бы.
С одной стороны, как «ИТ-шник», не могу не согласиться. С другой стороны, как «ИТ-шник», не согласен. Если рассматривать ИТ как ИНФОРМАЦИОННЫЕ технологии, то — все верно, именно «ИТ-шник» должен отвечать за информационный обмен в организации. Но если рассматривать вопрос по существу — я только в одной организации видел, чтобы служба ИТ занималась хотя бы экспертной поддержкой в области информационного обмена. В остальных организациях за это отвечали все, кто осуществлял информационный обмен, а главным безответственным лицом (потому как очень трудно отвечать за то, чем, по сути, не владеешь и чего, как правило, не умеешь, да и просто некогда) был Главный Инженер.
Поэтому — несмотря на «системноссь мышленья» отдельных лиц, без желания, поддержки и адекватности руководства такие дела не сдвигаются. Если руководству оно не надо — все, кому оно тоже не надо, ничего делать не будут, т.к. даже если и приказ есть, по попе все равно не нахлопают, можно просто сидеть и хихикать на техучебе, отпуская остроумные замечания на тему «а если Ванечка ушел в отпуск — тогда как?».
Поэтому — несмотря на «системноссь мышленья» отдельных лиц, без желания, поддержки и адекватности руководства такие дела не сдвигаются. Если руководству оно не надо — все, кому оно тоже не надо, ничего делать не будут, т.к. даже если и приказ есть, по попе все равно не нахлопают, можно просто сидеть и хихикать на техучебе, отпуская остроумные замечания на тему «а если Ванечка ушел в отпуск — тогда как?».
Технологов еще не хватает для полного комплекта. И можно добавить, что надо четко описать первичные результаты, которые должны быть получены в результате внедрения — четкие, конкретные, измеримые.
Как ты прав про гондурасов и курилки… Но есть один действенный способ их нейтрализовывать — по мере реализации проекта широко освещать все достижения для всех пользователей системы. Можно одной кнопкой сложный отчет получить — сразу рассказывать и показывать, операцию можно сделать не за 15 минут, а за 3 — тоже. Тогда таких гондурасов народ сам бить начнет (в идеале) или посылать как минимум. Плюс такой подход сплачивает (или как там правильно ?) команду внедрения, что утраивает силы, потому что у главных голова болит о многих вопросах, а успех от внедрения будет хорошим драйвером.
Вот последние пару недель все размышляю кое-над чем, думал с тобой об этом поговорить, но почитал статью и задумался… предварительную работу надо еще большую проводить, чтобы риски минимизировать. ((
Как ты прав про гондурасов и курилки… Но есть один действенный способ их нейтрализовывать — по мере реализации проекта широко освещать все достижения для всех пользователей системы. Можно одной кнопкой сложный отчет получить — сразу рассказывать и показывать, операцию можно сделать не за 15 минут, а за 3 — тоже. Тогда таких гондурасов народ сам бить начнет (в идеале) или посылать как минимум. Плюс такой подход сплачивает (или как там правильно ?) команду внедрения, что утраивает силы, потому что у главных голова болит о многих вопросах, а успех от внедрения будет хорошим драйвером.
Вот последние пару недель все размышляю кое-над чем, думал с тобой об этом поговорить, но почитал статью и задумался… предварительную работу надо еще большую проводить, чтобы риски минимизировать. ((
Батенька, как вы наивны… «гондурасов» коллеги никогда не пошлют, это ведь себе дороже, потому что у «гондураса» есть начальник, который, скорее всего, тоже «гондурас», ну или хотя бы сочувствующий… Все «сложные отчеты» — это не более как повод повосхищаться и больше никогда, НИКОГДА(!!!) эту кнопку (!!!) НЕ НАЖИМАТЬ (!!!). Потому как все хотят, назовем это так, работать (хотя, кого я обманываю, не работать, а просиживать штанцы или юбки). И чем меньше за ту же зп — тем лучше. Вы просто не учитываете того, что чем дольше выполняется поручение — тем значительней оно по своей важности. И никто никогда вам не расскажет нюансов того, как оно выполняется, чтобы вы, не дай Бог, не автоматизировали его.
Работает только одно — если руководство поддерживает, то нужно воздействовать на начальников означенных «гондурасов». Сначала — в личной беседе (тут обнаруживается разделение на «хитро-тупых» и просто «тупых»; договориться возможно, по моему опыту, в 10% случаев, не более), а потом — на ковер. Ну и, как вы понимаете, из-за этого возможны эксцессы. Если вы недостаточно разобрались в том, как работает предприятие, если вы не можете ответить на вопрос «что мне делать, чтобы отразить эту ситуацию в системе?» — это ваш личный риск вылететь к чертовой бабушке с волчьим билетом.
опа, а ведь 14-й год, однако… извините, просто задело…
Работает только одно — если руководство поддерживает, то нужно воздействовать на начальников означенных «гондурасов». Сначала — в личной беседе (тут обнаруживается разделение на «хитро-тупых» и просто «тупых»; договориться возможно, по моему опыту, в 10% случаев, не более), а потом — на ковер. Ну и, как вы понимаете, из-за этого возможны эксцессы. Если вы недостаточно разобрались в том, как работает предприятие, если вы не можете ответить на вопрос «что мне делать, чтобы отразить эту ситуацию в системе?» — это ваш личный риск вылететь к чертовой бабушке с волчьим билетом.
опа, а ведь 14-й год, однако… извините, просто задело…
Батенька, говоря про гондурасов, я имел в виду как раз линейный персонал. ))
Бывает по-всякому, я видел разное на проектах. Честно говоря, лень разводить срачь по этому поводу.
Бывает по-всякому, я видел разное на проектах. Честно говоря, лень разводить срачь по этому поводу.
Срач разводить, дейтсвительно, не будем.
Но все же — что такое «линейный персонал»? Если это — «кассиры, продавцы, рабочие, учителя, врачи, агенты страхования, менеджеры по продажам, операторы, строители, консультанты, официанты, банковские клерки и прочее», то склонен не согласиться с вами при всем уважении. На мой взгляд (подчеркну, чтобы срач не разводить), их вина только в том, что они хотят «сидеть на попе ровно» (слышал однажды такое выражение), они только стабилизируют болото. А вот источником процесса заболачивания являются их руководители. У них есть все полномочия, чтобы изменить процесс, но они ими не пользуются. Хотя это их обязанность.
Но все же — что такое «линейный персонал»? Если это — «кассиры, продавцы, рабочие, учителя, врачи, агенты страхования, менеджеры по продажам, операторы, строители, консультанты, официанты, банковские клерки и прочее», то склонен не согласиться с вами при всем уважении. На мой взгляд (подчеркну, чтобы срач не разводить), их вина только в том, что они хотят «сидеть на попе ровно» (слышал однажды такое выражение), они только стабилизируют болото. А вот источником процесса заболачивания являются их руководители. У них есть все полномочия, чтобы изменить процесс, но они ими не пользуются. Хотя это их обязанность.
Не все хотят ровно сидеть на попе. Вы пробовали собрать ведомости материалов и покупнины с нормами, например, для изделия с 15-20 тыс. ДСЕ, когда срок их был «вчера»? Тут без автоматизации застрелиться только. Примеров может быть масса.
Руководитель руководителю рознь. Я видел разных, опять же. Хороший рукль всегда создает эффективную систему, которая будет работать и с ним, и без него (в отпуске он, болеет, в командировке). И для такой системы разумные изменения (улучшения) всегда будут приветствоваться. Плохой рукль будет стараться управлять вручную, гасить любую инициативу (и возможных своих конкурентов в том числе). И тогда будет болото.
Автоматизация процессов, если она сделана честно и правильно, оставляет мало шансов катать вату.
Руководитель руководителю рознь. Я видел разных, опять же. Хороший рукль всегда создает эффективную систему, которая будет работать и с ним, и без него (в отпуске он, болеет, в командировке). И для такой системы разумные изменения (улучшения) всегда будут приветствоваться. Плохой рукль будет стараться управлять вручную, гасить любую инициативу (и возможных своих конкурентов в том числе). И тогда будет болото.
Автоматизация процессов, если она сделана честно и правильно, оставляет мало шансов катать вату.
«Не все хотят ровно сидеть на попе» — тем и живем. И, кстати, основную массу тех, кто хочет, я склонен считать также полезными членами общества — они, по крайней мере, не будут возражать против изменений, если изменения войдут в культуру предприятия. Они будут стабилизировать любую культуру. Есть, однако, «неолуддиты» (они же упомянутые «гондурасы»). Так вот у них, как раз, однозначно есть рукль, который им разрешает быть «гондурасами». И этот начальник — или тоже «гондурас», или сочувствующий, или просто дур не соответствует должности. Вот он и виноват.
По хорошим руклям согласен, но не стоит связывать хорошие качества рукля с приемлемостью им автоматизации. Он может передумать, когда увидит пользу или поймет, что этого не избежать. Но для этого он должен понять, что вы правы (а это не всегда очевидно даже вам) и должен верить в ваш опыт (а в это не всегда верите вы).
По хорошим руклям согласен, но не стоит связывать хорошие качества рукля с приемлемостью им автоматизации. Он может передумать, когда увидит пользу или поймет, что этого не избежать. Но для этого он должен понять, что вы правы (а это не всегда очевидно даже вам) и должен верить в ваш опыт (а в это не всегда верите вы).
Если у проекта внедрения более одного руководителя (максимум — более двух) — проект обречен.
Если причина внедрения " у всех есть, а мы что хуже?" — проект является чистым выбросом средств на ветер.
Если для внедрения нужно переписать более ~20% бизнес процессов в типовой «взрослой» ERP — компания требует кардинального пересмотра управления в первую очередь, а внедрение такой кастомизированной ERP системы если и закончится когда-либо, то положительного эффекта не даст никакого.
Если причина внедрения " у всех есть, а мы что хуже?" — проект является чистым выбросом средств на ветер.
Если для внедрения нужно переписать более ~20% бизнес процессов в типовой «взрослой» ERP — компания требует кардинального пересмотра управления в первую очередь, а внедрение такой кастомизированной ERP системы если и закончится когда-либо, то положительного эффекта не даст никакого.
Если для внедрения нужно переписать более ~20% бизнес процессов в типовой «взрослой» ERP — компания требует кардинального пересмотра управления в первую очередь, а внедрение такой кастомизированной ERP системы если и закончится когда-либо, то положительного эффекта не даст никакого.
Мне мой опыт говорит об обратном:
1) постоянная модификация существующих процессов (не обязательно глобальная, но достаточная для того, чтоб требовались изменения в учетной системе) — это нормальный процесс.
2) далеко не всегда разумно использовать «типовой» БП из «взрослой» ЕРП. Порой бывает даже так, что на двух соседних участках специфика различается настолько, что приходится делать разные БП.
3) процесс автоматизации учета сродни ремонту — нельзя закончить, можно прервать.
Мне мой опыт говорит об обратном:
1) постоянная модификация существующих процессов (не обязательно глобальная, но достаточная для того, чтоб требовались изменения в учетной системе) — это нормальный процесс.
2) далеко не всегда разумно использовать «типовой» БП из «взрослой» ЕРП. Порой бывает даже так, что на двух соседних участках специфика различается настолько, что приходится делать разные БП.
3) процесс автоматизации учета сродни ремонту — нельзя закончить, можно прервать.
1) Согласен. Более того, если предприятие приучено к этой мысли — у него есть шанс удержаться при любых внешних условиях.
2) И тут согласен. Хотя пересмотра исключать не стоит.
3) Вот тут… не знаю… опыта пока, наверное, мало… но если внешние изменения не касаются — можно и закончить. Пока не касаются.
2) И тут согласен. Хотя пересмотра исключать не стоит.
3) Вот тут… не знаю… опыта пока, наверное, мало… но если внешние изменения не касаются — можно и закончить. Пока не касаются.
Не согласен с тем, что руководить проектом должен либо генеральный директор, либо зам. генерального. На мой взгляд, руководить проектом должен руководитель проекта, и уж точно не генеральный директор.
Проект внедрения ERP (да и любой другой сложной системы, затрагивающей множество людей и подразделений) зачастую занимает полный рабочий день одного менеджера проектов. И соответственно этим должен заниматься человек, который будет:
а) ответственен за этот проект (то есть, с которого будет спрашивать результат и который будет за этот результат отвечать)
б) иметь все необходимые полномочия, уважение и власть (то есть, в случае чего он должен будет заставить любого из сотрудников работать на благо проекта или решить проблему не эскалируя ее наверх).
Если же вы этим будут заниматься существующие сотрудники или директора, то текучка, рутинные обязанности, которые никто с них не заберет просто не позволят им и работать хорошо и заниматься проектом.
Важный момент в случае отдельного руководителя проектов — это то, что руководство компании (генеральный и все остальные директора) должны быть заинтересованы в проекте. То есть, они не просто должны декларировать это, они должны всем своим поведением и работой быть заинтересованы. В некоторых случаях, бонусы руководства должны быть привязаны к успеху проекта.
Еще важный момент — это все подразделения должны быть заинтересованы, мотивированы в работе в ERP. То есть, это не только закупки и производство. Если у вас производство и закупки работают в единой системе, а продажи и склад нет — то производство и закупки вынуждены каждый раз звонить\идти на склад, чтобы узнать остатки, а продажники будут отвлекать производство, чтобы узнать когда будет сделан заказ и какие планы.
And last, but not least — рыдовые сотрудники. Абсолютно все значимые сотрудники, должны со временем перейти на работу в ERP он-лайн. То есть, для склада это должно быть «Отгрузил — внес в систему», а не целый день отгружаю, вечером\на следующее утро вношу. В связи с этим, зачастую встает огромный вопрос — обучение целого пласта сотрудников, которые зачастую никогда даже с компьютером не работали. Но это совершенно отдельная тема.
Проект внедрения ERP (да и любой другой сложной системы, затрагивающей множество людей и подразделений) зачастую занимает полный рабочий день одного менеджера проектов. И соответственно этим должен заниматься человек, который будет:
а) ответственен за этот проект (то есть, с которого будет спрашивать результат и который будет за этот результат отвечать)
б) иметь все необходимые полномочия, уважение и власть (то есть, в случае чего он должен будет заставить любого из сотрудников работать на благо проекта или решить проблему не эскалируя ее наверх).
Если же вы этим будут заниматься существующие сотрудники или директора, то текучка, рутинные обязанности, которые никто с них не заберет просто не позволят им и работать хорошо и заниматься проектом.
Важный момент в случае отдельного руководителя проектов — это то, что руководство компании (генеральный и все остальные директора) должны быть заинтересованы в проекте. То есть, они не просто должны декларировать это, они должны всем своим поведением и работой быть заинтересованы. В некоторых случаях, бонусы руководства должны быть привязаны к успеху проекта.
Еще важный момент — это все подразделения должны быть заинтересованы, мотивированы в работе в ERP. То есть, это не только закупки и производство. Если у вас производство и закупки работают в единой системе, а продажи и склад нет — то производство и закупки вынуждены каждый раз звонить\идти на склад, чтобы узнать остатки, а продажники будут отвлекать производство, чтобы узнать когда будет сделан заказ и какие планы.
And last, but not least — рыдовые сотрудники. Абсолютно все значимые сотрудники, должны со временем перейти на работу в ERP он-лайн. То есть, для склада это должно быть «Отгрузил — внес в систему», а не целый день отгружаю, вечером\на следующее утро вношу. В связи с этим, зачастую встает огромный вопрос — обучение целого пласта сотрудников, которые зачастую никогда даже с компьютером не работали. Но это совершенно отдельная тема.
А почему бы не сделать так, что результат каждого действия в системе оценивает постановщик задачи?
Например, производству требуется 4 гайки (понятно, что это тоже для выполнения какой-то цели, поставленной производству), оно говорит складу: приготовить 4 гайки. Человек на складе, собирает их в коробочку и в системе отмечает, что заказ собран. Главный момент: заказ считается собранным, когда это подтвердит в своем интерфейсе человек из производства. Если на выполнение этой задачи есть какой-то норматив времени, то человек со склада будет на производстве джигу танцевать, лишь бы постановщик задачи скорей принял заказ.
Таким образом и данных вводить меньше и каждый «чих» внесен в систему, собирается статистика по нагрузке отделов, среднее время выполнения операции и т.д.
Например, производству требуется 4 гайки (понятно, что это тоже для выполнения какой-то цели, поставленной производству), оно говорит складу: приготовить 4 гайки. Человек на складе, собирает их в коробочку и в системе отмечает, что заказ собран. Главный момент: заказ считается собранным, когда это подтвердит в своем интерфейсе человек из производства. Если на выполнение этой задачи есть какой-то норматив времени, то человек со склада будет на производстве джигу танцевать, лишь бы постановщик задачи скорей принял заказ.
Таким образом и данных вводить меньше и каждый «чих» внесен в систему, собирается статистика по нагрузке отделов, среднее время выполнения операции и т.д.
Вы немного отвлеклись от темы про внедрение ERP, на то, как и какие события должны отражаться в системе.
Ваша идея верна, но нужна идти дальше. Разберем Ваш кейс — зав.производству нужны 4 гайки. В Вашем комментарии — у данного процесса три этапа: зав.производством заказал, заказ собирают, заказ выполнен.
На самом деле все сложнее (не будем отвлекаться на то, что зав. производство обычно заказывает примерно так «Петрович, позвони Васе, пусть он 4 гайки закажет» :)) — заказ сделан, заказ собирают, заказ собран, и тут самое интересное — отгрузка со склада. То есть, кладовщик собрал и отдал заказ. С точки зрения кладовщика заказ выполнен, с точки зрения производства не выполнен, потому что гаек то у него нет. Где гайки то? А гайки они у водителя, который везет их из склада в цех (например в сельском хозяйстве расстояние может быть десятки километров по проселочным дорогам на уазике). И если он их не довезет, то это не вина кладовщика и как бы он джигу не танцевал, на водителя он не оказывает никакого влияния.
То есть, решение что результат оценивает постановщик задачи оно половинчастое, в данном случае надо отмечать в системе, когда заказ поступил, когда его отгрузили и когда он поступил к заказчику. И анализировать все это время.
Насчет оценки времени — тут тоже есть нюанс, который зовется очередью. То есть у кладовщика может быть на момент получения заказа еще 100 заказов и он их будет выполнять по очереди. Тогда к оценке надо добавлять еще параметр «Заказ принят к исполнению», а не просто оценивать сколько времени с момента получения заказа.
К тому же не следует забывать о том, что кладовщики зачастую не самые образованные и компетентные в компьютерах люди, и на то, чтобы собрать 4 гайки и 2 рессоры у него уйдет 5 минут, а чтобы их 1 пальцем набить на клавиатуре еще 20. В этом случае надо оценивать загрузку кладовщика и или садить отдельного оператора или думать в сторону DWH системы или штрихкодирования.
Ваша идея верна, но нужна идти дальше. Разберем Ваш кейс — зав.производству нужны 4 гайки. В Вашем комментарии — у данного процесса три этапа: зав.производством заказал, заказ собирают, заказ выполнен.
На самом деле все сложнее (не будем отвлекаться на то, что зав. производство обычно заказывает примерно так «Петрович, позвони Васе, пусть он 4 гайки закажет» :)) — заказ сделан, заказ собирают, заказ собран, и тут самое интересное — отгрузка со склада. То есть, кладовщик собрал и отдал заказ. С точки зрения кладовщика заказ выполнен, с точки зрения производства не выполнен, потому что гаек то у него нет. Где гайки то? А гайки они у водителя, который везет их из склада в цех (например в сельском хозяйстве расстояние может быть десятки километров по проселочным дорогам на уазике). И если он их не довезет, то это не вина кладовщика и как бы он джигу не танцевал, на водителя он не оказывает никакого влияния.
То есть, решение что результат оценивает постановщик задачи оно половинчастое, в данном случае надо отмечать в системе, когда заказ поступил, когда его отгрузили и когда он поступил к заказчику. И анализировать все это время.
Насчет оценки времени — тут тоже есть нюанс, который зовется очередью. То есть у кладовщика может быть на момент получения заказа еще 100 заказов и он их будет выполнять по очереди. Тогда к оценке надо добавлять еще параметр «Заказ принят к исполнению», а не просто оценивать сколько времени с момента получения заказа.
К тому же не следует забывать о том, что кладовщики зачастую не самые образованные и компетентные в компьютерах люди, и на то, чтобы собрать 4 гайки и 2 рессоры у него уйдет 5 минут, а чтобы их 1 пальцем набить на клавиатуре еще 20. В этом случае надо оценивать загрузку кладовщика и или садить отдельного оператора или думать в сторону DWH системы или штрихкодирования.
Судя по примеру со штрихкодом, у меня получилось донести мысль. А вот пример с водителем показывает обратное. Кладовщик обязан собрать и отдать. Кому именно — его волновать не должно. Он со своей задачей уже справился. В вашем примере выполнение заказа кладовщиком должен принять водитель, а доставку водителем — производство.
А нюанс про 100 заказов и призвана решить система, насколько я понимаю причины ее внедрения, то есть, либо производство в момент постановки задачи увидит, что в ближайшие три дня гаек не будет, либо директор увидит, что от одного единственного подразделения с не самой высокооплачиваемой работой простаивает весь завод, так как по факту задержки склада откладывает срок сдачи готового продукта.
А нюанс про 100 заказов и призвана решить система, насколько я понимаю причины ее внедрения, то есть, либо производство в момент постановки задачи увидит, что в ближайшие три дня гаек не будет, либо директор увидит, что от одного единственного подразделения с не самой высокооплачиваемой работой простаивает весь завод, так как по факту задержки склада откладывает срок сдачи готового продукта.
Пример с кладовщиком и водителем не показывает обратное, он просто углубляет. То есть, система имеет отношение не один к одному (А поставил задачу — Б выполнил — А принял), а задача последовательна (А поставил — Б выполнил — В выполнил — А принял).
Ну а так, все остальное верно. Зачастую самые низкооплачиваеые люди могут тормозить все производство и никакие ERP не решат эту проблему. Она решается только тем, что надо дружить с головой :)
Ну а так, все остальное верно. Зачастую самые низкооплачиваеые люди могут тормозить все производство и никакие ERP не решат эту проблему. Она решается только тем, что надо дружить с головой :)
Немного похоже на паттерн про интерфейс, или еще подобный из GoF. Производству не обязательно знать откуда принесут гайки. Просто надо знать, куда об этом сказать. А там уже пусть система решает, толи взять из местного запаса, толи купить у поставщиков, толи свой завод металлургический строить начать.
На мой взгляд, руководить проектом должен руководитель проекта, и уж точно не генеральный директор.
И тут же:
иметь все необходимые полномочия, уважение и власть (то есть, в случае чего он должен будет заставить любого из сотрудников работать на благо проекта или решить проблему не эскалируя ее наверх).
Ваше условие б) — это и есть власть уровня генерального или зама генерального :).
Судя по тексту статьи, ГД или ЗГД не собираются делать менеджером проекта. Однако нужен топ, кровно в проекте заинтересованный. Тот, который будет драть три шкуры с менеджера проекта и разъяснять политику партии тем сотрудникам, которые на проект работать не хотят. Вы, собственно, пишете то же самое:
… руководство компании (генеральный и все остальные директора) должны быть заинтересованы в проекте. То есть, они не просто должны декларировать это, они должны всем своим поведением и работой быть заинтересованы.
Иными словами, я с Вами согласен в содержательной части, но с автором я согласен тоже. На мой взгляд, вы друг другу не противоречите совершенно.
И тут же:
иметь все необходимые полномочия, уважение и власть (то есть, в случае чего он должен будет заставить любого из сотрудников работать на благо проекта или решить проблему не эскалируя ее наверх).
Ваше условие б) — это и есть власть уровня генерального или зама генерального :).
Судя по тексту статьи, ГД или ЗГД не собираются делать менеджером проекта. Однако нужен топ, кровно в проекте заинтересованный. Тот, который будет драть три шкуры с менеджера проекта и разъяснять политику партии тем сотрудникам, которые на проект работать не хотят. Вы, собственно, пишете то же самое:
… руководство компании (генеральный и все остальные директора) должны быть заинтересованы в проекте. То есть, они не просто должны декларировать это, они должны всем своим поведением и работой быть заинтересованы.
Иными словами, я с Вами согласен в содержательной части, но с автором я согласен тоже. На мой взгляд, вы друг другу не противоречите совершенно.
Я никак не противоречу автору, я просто уточняю его (так как я понимаю).
На самом деле, в реальных компаниях, зачастую менеджеры крупных и значимых проектов, не являясь генеральным или каким-то еще директором, могут заставить\убедить\уговорить других сотрудников, даже которые им не подчиняются, даже директоров, выполнять необходимые для проекта задачи. Для этого и нужны менеджеры проектов. В теории такой тип власти может называться референтной.
У ГД, ЗГД или просто каких-то Д в реальности куча задач связанных с операционной деятельностью компании и, в реальности, они не будут полностью отдаваться проекту. Для этого есть МП, который дерет со всех три шкуры и разъясняет политику. В свою очередь с МП дерет три шкуры менеджмент компании (те самые ГД и ЗГД). ГД просто уполномачивает его в рамках проекта на все необходимые действия. То есть по большому счету, можно нанять менеджера проекта и назвать его должность «Вице-президент по внедрению ERP», но по факту так не делают (я думаю потому что ВП надо платить большую зарплату чем МП :).
На самом деле, в реальных компаниях, зачастую менеджеры крупных и значимых проектов, не являясь генеральным или каким-то еще директором, могут заставить\убедить\уговорить других сотрудников, даже которые им не подчиняются, даже директоров, выполнять необходимые для проекта задачи. Для этого и нужны менеджеры проектов. В теории такой тип власти может называться референтной.
У ГД, ЗГД или просто каких-то Д в реальности куча задач связанных с операционной деятельностью компании и, в реальности, они не будут полностью отдаваться проекту. Для этого есть МП, который дерет со всех три шкуры и разъясняет политику. В свою очередь с МП дерет три шкуры менеджмент компании (те самые ГД и ЗГД). ГД просто уполномачивает его в рамках проекта на все необходимые действия. То есть по большому счету, можно нанять менеджера проекта и назвать его должность «Вице-президент по внедрению ERP», но по факту так не делают (я думаю потому что ВП надо платить большую зарплату чем МП :).
НЛО прилетело и опубликовало эту надпись здесь
Кстати, «Старо и недоброе объемно-календарное планирование» вполне успешно работает в сельском хозяйстве, так что не стоит его выбрасывать сразу.
Это был пример использования годного инструмента в неправильных целях. Если производство позаказное, а вам предлагают старое и недоброе “объемно-календарное планирование”, то провозитесь пару-тройку лет и плюнете. СХ не может быть позаказным, там сажать нужно тогда, когда нужно сажать, а не тогда, когда заказ пришёл :).
То есть объёмно-календарное планирование бывает плохим так же, как плох чеснок в шоколадном торте: когда оно неуместно.
То есть объёмно-календарное планирование бывает плохим так же, как плох чеснок в шоколадном торте: когда оно неуместно.
Успешное внедрение в первую очередь зависит от успешности компании, т.е. должна четко работать бизнес модель и налажены все бизнес процессы. Во вторую очередь от персонала, именно персонал и его квалификация играет ключевую роль при внедрении таких систем.
До начала внедрения, все бизнес процессы должны быть полностью прозрачны и контролируемы. Необходимо искоренить или хотя бы минимизировать все коррупционные составляющие. Провести кадровую оценку, обучить или уволить ИТР работников, не умеющих работать на ПК, а таких обычно очень много, особенно на заводах. Иначе внедрении ERP системы будет тянуться годами а из Компании будут просто выкачиваться деньги, и конечно же эффекта никакого не будет.
До начала внедрения, все бизнес процессы должны быть полностью прозрачны и контролируемы. Необходимо искоренить или хотя бы минимизировать все коррупционные составляющие. Провести кадровую оценку, обучить или уволить ИТР работников, не умеющих работать на ПК, а таких обычно очень много, особенно на заводах. Иначе внедрении ERP системы будет тянуться годами а из Компании будут просто выкачиваться деньги, и конечно же эффекта никакого не будет.
Но если бизнес модель в компании так хороша, что ERP не способна радикально её улучшить, то нужна ли там ERP?
Нужна. Помогает видеть реальную детальную текущую картину предприятия (E) по ресурсам (R), и на этой основе лучше их планировать (P).
Ваш К.О. :-)
Ваш К.О. :-)
Хотите сказать, что видение всего этого не должно поменять бизнес-модель? Будут лишь точнее планировать ресурсы, оставив всё остальное по-прежнему?
— Ну мы ведь про идеальную компанию, сейчас? Хотя, всегда есть что улучшать.
Мы про такую, какой должна быть компания, чтобы получить успешное внедрение — по мнению sarbash.
Ну ERP это ж не только планирование, это еще и учет. Зачастую в больших компаниях бывает, что учетных систем стоит несколько — бухгалтерия одна, склад другая, кадры третья, производство — четвертая + Ексель, отчеты для топов делает целый отдел (который ничем другим кроме вытаскивания цифр из разных систем не занимается).
С одной стороны все работает, все бизнес-процессы построены, но получить, для примера, себестоимость можно потратив две недели сводя циферки в Екселе.
С одной стороны все работает, все бизнес-процессы построены, но получить, для примера, себестоимость можно потратив две недели сводя циферки в Екселе.
ERP это инструмент позволяющий успешной компании стать еще более успешной, а именно оптимизировать и экономить огромные ресурсы, и чем больше компания тем большим будет эффект от внедрения ERP. Она позволит более эффективно управлять, значительно снизить затраты, и себестоимость продукции, увеличить скорость всех процессов и производства в целом, повысить конкурентоспособность в общем позволит подняться на более высокий уровень, приближенный к идеальному. К тому же современный бизнес довольно динамичен, очень часто нужно что-то менять, развивать другие направления, внедрять новое оборудование и технологии и т.п. и если есть ERP система то она позволяет делать это наиболее эффективно и быстро.
Часто бывает так что инвесторы, акционеры в общем владельцы не знают реального положения в компании, а на самом деле там процветает коррупция, воровство, взятки, круговая порука, отчеты фабрикуются, искажаются и т.п., компания хорошо пиарится и с виду посмотреть вроде как компания успешная, а начнешь разбираться и оказывается что все просто очень и очень плохо.
Часто бывает так что инвесторы, акционеры в общем владельцы не знают реального положения в компании, а на самом деле там процветает коррупция, воровство, взятки, круговая порука, отчеты фабрикуются, искажаются и т.п., компания хорошо пиарится и с виду посмотреть вроде как компания успешная, а начнешь разбираться и оказывается что все просто очень и очень плохо.
Ну вообще-то для того, чтобы узнать реальное положение дел в компании, нужно не ERP внедрять, а нанимать независимый аудит. Никто не мешает фальсифицировать отчеты и в ERP.
совершенно верно, поэтому я и написал что
Фальсифицировать отчеты в реально работающей ERP системе практически невозможно, т.к. изменения одних показателей сразу выльется в перекос других, корректировка которых может привести сразу к полному дисбалансу и искажениям, в аналитических отчетах будут видны перекосы и т.п. Т.е. реально чтобы сфальсифицировать отчеты ERP необходимо чтобы одновременно десятки сотрудников в разных департаментах и направлениях начали вводить неправильные данные, одновременно организовать реальные действия ввоз/вывоз, денежные переводы и т.д, т.е. должна быть четкая организация и координация действий, что на практике практически невозможно, кроме того высока вероятность ошибки, что все равно в итоге выльется в дисбаланс и видно будет в аналитических отчетах за большой период времени.
А если например производство еще имеет очень высокий уровень автоматизации, роботизации, то многие данные могут заходить в систему прямо с оборудования, например со счетчиков конвейера, упаковочных автоматов и т.п., так что в таких случаях фальсификации практически исключены и чреваты полной остановкой автоматизированных линий и цехов.
Успешное внедрение в первую очередь зависит от успешности компаниии если хотите можно добавить " подтвержденной независимым аудитом"
Фальсифицировать отчеты в реально работающей ERP системе практически невозможно, т.к. изменения одних показателей сразу выльется в перекос других, корректировка которых может привести сразу к полному дисбалансу и искажениям, в аналитических отчетах будут видны перекосы и т.п. Т.е. реально чтобы сфальсифицировать отчеты ERP необходимо чтобы одновременно десятки сотрудников в разных департаментах и направлениях начали вводить неправильные данные, одновременно организовать реальные действия ввоз/вывоз, денежные переводы и т.д, т.е. должна быть четкая организация и координация действий, что на практике практически невозможно, кроме того высока вероятность ошибки, что все равно в итоге выльется в дисбаланс и видно будет в аналитических отчетах за большой период времени.
А если например производство еще имеет очень высокий уровень автоматизации, роботизации, то многие данные могут заходить в систему прямо с оборудования, например со счетчиков конвейера, упаковочных автоматов и т.п., так что в таких случаях фальсификации практически исключены и чреваты полной остановкой автоматизированных линий и цехов.
Фальсифицировать отчетность в реально работающей ERP очень просто, надо фальсифицировать вводимые данные. Поверьте shareholder-ы, акционеры и владельцы не будут смотреть данные в ERP, которые приходят с конвейера, оно им не надо, их интересует только финансовая отчетность. Если речь идет о крупных компаниях с тысячами рабочих места и тысячами операций в день, то «правильная» методология руководства компании позволит показать все совсем не так, как есть на самом деле.
Вот классический пример http://ru.wikipedia.org/wiki/Enron, а ведь у них тоже была наверняка ERP.
Вот классический пример http://ru.wikipedia.org/wiki/Enron, а ведь у них тоже была наверняка ERP.
конечно же
они будут смотреть отчеты построенные на макропоказателях, которые как раз берутся с множества конвейеров, складов, оборотных средств, с продаж и т.д. Например кто-то решил что-то украсть и сфальсифицировать данные, скажем готовую продукцию «украли» прямо с конвейера и вывезли его по липовым накладным, можно либо уменьшить количество, списать на брак, и др.., НО в системе будет видно что потрачено больше сырья, запчастей возникает недостача. это называется дисбаланс, потом где-то не прошло считывание штрихкода, ввоз-вывоз и т.д. т.е. это будет сразу видно уже в промежуточных отчетах будут минусы и красным цветов выделено. Чтобы это сработало хотя бы раз нужно договориться чтобы «правильные» данные ввели на складах, чтобы сфальсифицировали ввод данных запасов сырья и комплектующих, уменьшить человеко-часы конвейеро и станко часы, уменьшили оборотные средства и т.д. А говорить о какой-то системности совсем сложно.
Кстати на счет Enron если бы там была современная ERP система то возможно этого не случилось, если там и была система то в 1990-2000 годах ERP системы только начинали свое развитие, их функционал был весьма ограничен несколькими направлениями, а глубина интеграции была очень поверхностной. Кстати сейчас в США для выхода на фондовый рынок публичных компаний обязательное требование наличие ERP системы.
акционеры и владельцы не будут смотреть данные в ERP, которые приходят с конвейера
они будут смотреть отчеты построенные на макропоказателях, которые как раз берутся с множества конвейеров, складов, оборотных средств, с продаж и т.д. Например кто-то решил что-то украсть и сфальсифицировать данные, скажем готовую продукцию «украли» прямо с конвейера и вывезли его по липовым накладным, можно либо уменьшить количество, списать на брак, и др.., НО в системе будет видно что потрачено больше сырья, запчастей возникает недостача. это называется дисбаланс, потом где-то не прошло считывание штрихкода, ввоз-вывоз и т.д. т.е. это будет сразу видно уже в промежуточных отчетах будут минусы и красным цветов выделено. Чтобы это сработало хотя бы раз нужно договориться чтобы «правильные» данные ввели на складах, чтобы сфальсифицировали ввод данных запасов сырья и комплектующих, уменьшить человеко-часы конвейеро и станко часы, уменьшили оборотные средства и т.д. А говорить о какой-то системности совсем сложно.
Кстати на счет Enron если бы там была современная ERP система то возможно этого не случилось, если там и была система то в 1990-2000 годах ERP системы только начинали свое развитие, их функционал был весьма ограничен несколькими направлениями, а глубина интеграции была очень поверхностной. Кстати сейчас в США для выхода на фондовый рынок публичных компаний обязательное требование наличие ERP системы.
Возможно мы с Вами говорим о разных shareholder-ах, но мой опыт говорит, что
а) никто из акционеров не будет смотреть на макропоказатели и тем более их сравнивать. Зачастую всех их интересует только P&L, Cashflow и красивая презеннтация сколько продукции произвели. Представьте себе Олега Дерипаску или Рената Ахметова, которого интересует сколько там брака было произведено на его заводе.
б) зачастую у них просто нет доступа к ERP или другим учетным системам.
Для того, чтобы это проверить и нанимают независимых аудиторов или делают свой отдел внутреннего аудита, который и должен искать это все.
а) никто из акционеров не будет смотреть на макропоказатели и тем более их сравнивать. Зачастую всех их интересует только P&L, Cashflow и красивая презеннтация сколько продукции произвели. Представьте себе Олега Дерипаску или Рената Ахметова, которого интересует сколько там брака было произведено на его заводе.
б) зачастую у них просто нет доступа к ERP или другим учетным системам.
Для того, чтобы это проверить и нанимают независимых аудиторов или делают свой отдел внутреннего аудита, который и должен искать это все.
возможно о разных, на самом деле это не играет роли, просто чем больше бизнес, тем сложнее его контролировать, я тоже думаю что Ренат Ахметов сам лично смотреть за каждым заводом не будет, но он поставит своего доверенного человека или компанию, которые должны следить за реальными показателями, контролировать заводы, проводить внутренний аудит регулярно и т.д. А независимый аудит периодически для дополнительного контроля.
Пример с Enron, показывает чем заканчиваются фальсификации отчетов и подкупы аудиторов… поэтому если компания не успешная и скрывает это, то внедрение ERP системы обречено на провал.
Пример с Enron, показывает чем заканчиваются фальсификации отчетов и подкупы аудиторов… поэтому если компания не успешная и скрывает это, то внедрение ERP системы обречено на провал.
С точки зрения бизнеса я бы еще добавил инструкции. Потому что люди меняются, одни уходят, другие приходят. Консультанты\подрядчики тоже не вечны, и со временем приходит ситуация, когда уже никто не знает\не помнит почему было сделано так и как вообще пользоваться функциями этой ERP.
НЛО прилетело и опубликовало эту надпись здесь
По внедрению ERP? На мой взгляд — не очень может.
Нет, я не тупой, я понимаю вашу шутку, я даже смеюсь, я только в ответ пошутить не могу адекватно… стоп… может, и тупой всё-таки…
Ладно, возвращаясь к нашим баранам.
По моему опыту ERP — не про IT совсем. Она про бизнес. И куратором проекта должен быть кто-то из бизнеса. Но участие IT всё-таки не ограничивается «настройкой системы и раздачей прав». Бизнес часто воспринимает IT как магию и не очень представляет, что ERP может, что нет. Вот для того, чтобы время от времени кураторабить мордой об стол спускать с небес на землю, IT-директор и нужен.
Мой личный опыт — бизнес придумал прекрасную идею учёта, а грубый айтишник сказал, что не пойдёт. Потому что вам нужно знать вот эти параметры, а их у вас нет. Потому что нет датчиков. Хотите поставить — куча денег и 2 месяца времени. Подумайте, этот кусок вам точно нужен?
Нет, я не тупой, я понимаю вашу шутку, я даже смеюсь, я только в ответ пошутить не могу адекватно… стоп… может, и тупой всё-таки…
Ладно, возвращаясь к нашим баранам.
По моему опыту ERP — не про IT совсем. Она про бизнес. И куратором проекта должен быть кто-то из бизнеса. Но участие IT всё-таки не ограничивается «настройкой системы и раздачей прав». Бизнес часто воспринимает IT как магию и не очень представляет, что ERP может, что нет. Вот для того, чтобы время от времени куратора
Мой личный опыт — бизнес придумал прекрасную идею учёта, а грубый айтишник сказал, что не пойдёт. Потому что вам нужно знать вот эти параметры, а их у вас нет. Потому что нет датчиков. Хотите поставить — куча денег и 2 месяца времени. Подумайте, этот кусок вам точно нужен?
НЛО прилетело и опубликовало эту надпись здесь
Господа, по-моему это спор ни о чем. Руководить проектом должен человек с обладающий необходимыми компетенциями. Это может быть директор по ИТ с финансовым образованием и многолетним пониманием бизнеса. С другой стороны финансовый или операционный директор завалит например кадровую часть ERP, просто потому, что не понимает ничего.
Не забывайте также о том, что у многих директоров вырабатывается особый высокоуровневый взгляд на бизнес-процессы компании. Он многие мелкие процессы которые лежат в основании (в самом низу) воспринимает как само собой разумеющиеся вещи.
По факту — есть ситуации, когда ИТ директор будет отлично рулить проектом, а любой человек из бизнеса его завалит. Хотя да, внедрение ERP это совсем не про ИТ, также как и например внедрение простой учетной системы это не только бухгалтерия.
Не забывайте также о том, что у многих директоров вырабатывается особый высокоуровневый взгляд на бизнес-процессы компании. Он многие мелкие процессы которые лежат в основании (в самом низу) воспринимает как само собой разумеющиеся вещи.
По факту — есть ситуации, когда ИТ директор будет отлично рулить проектом, а любой человек из бизнеса его завалит. Хотя да, внедрение ERP это совсем не про ИТ, также как и например внедрение простой учетной системы это не только бухгалтерия.
Yggaz, Вы немного противоречите себе. Вы сначала пишете, что руководить процессом ИТ-шник не может, а потом пишите, что куратором должен быть кто-то из бизнеса. Но руководитель проекта и куратор (спонсор) проекта это две совсем разные роли. Да, они могут совмещаться, но это разные роли.
А еще бывает так: контора давно работает, получает прибыль, вроде все стабильно. И каждый человек знает, что он должен делать, и он это делает, только не знает нафига, на вопрос «зачем ?» — следует ответ «Так было всегда еще до меня». Если контора небольшая, то не страшно — разберемся, а вот когда покрупнее, приходится конкретно попотеть, что бы понять для чего некоторые сотрудники бьют в бубен
Спасибо автору за статью. Очень нравятся статьи, где автор передаёт профессиональный опыт, а не констатирует всем известные факты.
Как человек, с опытом разработки систем учета на 3 различных предприятиях (на двух — с нуля, на третьем — глубокая модернизация существующей учетной системы) могу сказать только одно: «Все так».
Могу добавить только вот к этому: «Если производство работает (хм, работает ли) в бардаке и он лично при этом никак не страдает и не чувствует опасности для себя, то такая ситуация даже лучше для него.» — вообще стоит смотреть, кому выгоден существующий бардак. И ждать с этой стороны серьезный палок в колеса. Классический пример — главный «безопасник», который через пару прикормленных мастеров организует «утечку» готовой продукции (или полуфабрикатов) с завода. Но тут нужен хороший опыт, чтоб чуять такие вещи.
Могу добавить только вот к этому: «Если производство работает (хм, работает ли) в бардаке и он лично при этом никак не страдает и не чувствует опасности для себя, то такая ситуация даже лучше для него.» — вообще стоит смотреть, кому выгоден существующий бардак. И ждать с этой стороны серьезный палок в колеса. Классический пример — главный «безопасник», который через пару прикормленных мастеров организует «утечку» готовой продукции (или полуфабрикатов) с завода. Но тут нужен хороший опыт, чтоб чуять такие вещи.
Прочитал первый абзац
На сколько знаю, «воз и ныне там». Уж лет 10 прошло.
Так тоже бывает…
… в котором изложить, что необходимо, чтобы внедрить систему.и сразу вспомнил случай из своей практики. История с внедрением ERP закончилась именно на этом. Я написал подробный план, передал заказчику, получил положенные деньги. Рассчитывал, что дальше будем работать с заказчиком по этому плану, а он решил передать план своим «айтишникам», дескать дальше пусть они все делают, строго по плану.
На сколько знаю, «воз и ныне там». Уж лет 10 прошло.
Так тоже бывает…
Возможно, заказчик просто честно оценил свой потенциал?
На самом деле — это была «вселенская хитрость»! От своих «айтишников» добиться плана действий директор не мог и сам свой план составить тоже не мог, поэтому решил нанять стороннего специалиста, получить от него план мероприятий и заставить своих «айтишников» по нему пройти. Руководящие и контролирующие функции оставлял за собой.
Он ошибочно полагал, что плана и его собственной инициативы достаточно. :)
P.S. По началу подобные подходы (это был не единственный случай) меня расстраивали, пока не взглянул на ситуацию иначе. Такие организации достойны результата своей работы. :)
Он ошибочно полагал, что плана и его собственной инициативы достаточно. :)
P.S. По началу подобные подходы (это был не единственный случай) меня расстраивали, пока не взглянул на ситуацию иначе. Такие организации достойны результата своей работы. :)
Ну, во первых менять систему мотивации. Она должна быть не от выработки участка, а от выработки завода. Чувствуете разницу? Одно дело, когда ваши люди замотивированы на рост незавершенки, и совсем другое дело, когда они замотивированы на выпуск продукции.
Вся мотивация четко по Голдратту, его теории ограничений (ТОС) и его книге «Цель».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Чтобы внедрить ERP-систему на производстве