Комментарии 12
им внедрили систему несколько лет назад, после этого свой отдел разработки (3-4 программиста) работал день и ночь, чтобы закрыть все «хотелки» пользователей. За это время они «убили» систему – в ней было невозможно работать, потому что все тормозило. Клиенту пришлось заново внедрять систему
Узнаю брата Колю — 1С франчайзинг.
Но вот вердикт «убили систему — все тормозило — пришлось заново внедрять» отдает дилетантством.
Но вот вердикт «убили систему — все тормозило — пришлось заново внедрять» отдает дилетантством.
Согласен, решение спорное. Но там при перевнедрении менялась версия системы, добавлялся новый функционал, который был действительно нужен заказчику. К тому же такие решения никогда не принимаются по одной простой технической причине («все тормозит — давайте разрушим старое и построим новое»), есть и организационные, и политические моменты.
В этом кейсе важен не факт перевнедрения (такая радикальная мера — скорее исключение), а мысль, что свой штат разработчиков при неаккуратном подходе может создать проблемы бизнесу.
есть и организационные, и политические моменты.
Перевнедрение — это адское количество организационных моментов, в угоду одному политическому моменту.
важен не факт перевнедрения (такая радикальная мера — скорее исключение)
Не согласен, в 1С сообществе это скорее правило. ) Допустим, в ходе внедрения есть некоторый недостаток компетенций, мощностей, коммуникаций, в результате чего накапливается негатив и принимается эмоциональное решение пригласить новых внедренцев и начать все заново. Допустим, старые — это свои программисты, а новые — аутсорсинг.
Скорее всего, новые внедренцы при оценке ситуации напирают на негативные моменты «убили систему, все тормозит», так как им это выгодно, чтобы продать проект заново, как новую машину, вместо старой с засорившейся пепельницей.
И как правило, новые внедренцы при примерно том же бюджете и сроках скорее всего выявят те же проблемы.
свой штат разработчиков при неаккуратном подходе может создать проблемы бизнесу
В заметке сказано, что они _решали_ проблемы бизнеса слишком рьяно, допустим, без приоритезации и без оценки затрат на поддержку.
Но очевидно, что анализ проблемы, которую они создали, вообще не проводился даже по apdex. «Убили систему — все тормозит» — это не серьезно, не бывает так чтоб тормозило прям все.
Это оценка продажника при первом контакте, но не эксперта по внедрению ERP.
Впрочем, это у меня возрастное, лет 10 назад я бы тоже даже не слушал че там эти дебилы предшественники накодили, и лоббировал внедрение Отличной Новой Версии 1С: УПП/ERP прям с порога. )
Анализ проблемы проводился, просто заметка была не об этом) В рамках примера я посчитал достаточной формулировку «все тормозит»)
Вы же сказали, что перевнедрение — это адское количество организационных моментов. Да, бюджет на внедрение новой системы, скорее всего, будет больше бюджета на сопровождение старой. Но и проблем и репутационных рисков будет существенно больше — по моему опыту, если существующую систему можно просто поддерживать, то интегратор тоже не сильно заинтересован в новом внедрении, можно спокойно совершенствовать то, что есть.
Скорее всего, новые внедренцы при оценке ситуации напирают на негативные моменты «убили систему, все тормозит», так как им это выгодно, чтобы продать проект заново, как новую машину, вместо старой с засорившейся пепельницей.
Вы же сказали, что перевнедрение — это адское количество организационных моментов. Да, бюджет на внедрение новой системы, скорее всего, будет больше бюджета на сопровождение старой. Но и проблем и репутационных рисков будет существенно больше — по моему опыту, если существующую систему можно просто поддерживать, то интегратор тоже не сильно заинтересован в новом внедрении, можно спокойно совершенствовать то, что есть.
увы, такое не редкость при удовлетворении всех хотелок
Все эти истории про внедрение ERP каждый раз напоминают мне бородатый анекдот:
Серьезно, у подавляющего большинства внедренцев установка — ваши бизнес процессы слишком сложны для нашей системы? Надо упростить их! Формализовать! (далее следуют голословные утверждения о пользе бизнесу) Вот только проблема в том, что сложность процессов зачастую возникает не на пустом месте…
Изобретен аппарат автоматического бритья:
— Бросаешь рубль, суешь голову в прорезь
и он тебя автоматически бреет.
— Но ведь у всех разные лица!?!?
— В первый раз да…
Серьезно, у подавляющего большинства внедренцев установка — ваши бизнес процессы слишком сложны для нашей системы? Надо упростить их! Формализовать! (далее следуют голословные утверждения о пользе бизнесу) Вот только проблема в том, что сложность процессов зачастую возникает не на пустом месте…
Как я уже писал, современные ERP-системы имеют избыточный функционал, — чаще возникает вопрос, каким из нескольких способов лучше реализовать то, что хочет заказчик. И большинство сложных процессов можно реализовать в системе путем настроек.
Проблемы, к сожалению, возникают не со сложными процессами, а со всякими «рюшечками», «мне так неудобно», желанием сохранить старые отчеты, для которых в новой системе есть аналоги, нежеланием вести в системе весь нужный объем информации и поддерживать данные актуальными.
Проблемы, к сожалению, возникают не со сложными процессами, а со всякими «рюшечками», «мне так неудобно», желанием сохранить старые отчеты, для которых в новой системе есть аналоги, нежеланием вести в системе весь нужный объем информации и поддерживать данные актуальными.
Кейс 5 — зачет. Только так и можно выкрутится в большинстве случаев. Варить кашу из топора — эффективный метод взаимодействия. Помимо остальных качеств для успеха дела нужна смекалка. И проблема №5 очень актуальна для внешних исполнителей. Когда «варишься» внутри любой кухни — собираешь знания, которые недоступны «чужим».
Что-то подсказывает, что к моменту начала опытной эксплуатации желательно реализовать большую часть функционала (хорошо бы весь) и формировать список необходимых организационных изменений может быть поздновато. Со своей колокольни (SAP) кажется, что стоит провести анализ существующих и внедряемых процессов, и определить, где будет система меняться, а где предприятие — ещё до начала настройки, в рамках концептуального проектирования.
В этом мы не отличаемся — уверен, при внедрении любой ERP-системы проводят этап концептуального планирования сильно раньше начала опытной эксплуатации. Как я и писал к началу опытной все модификации реализованы, все прекрасно понимают, где изменена система, а где бизнес-процессы будут работать по-другому, есть написанные дизайны или СТП, инструкции, правила кодирования и т.д.:
Проблема не в отсутствии этого этапа. Проблема в том, что на этапе опытной эксплуатации начинаются попытки переиграть те согласованные и закрепленные в регламентах решения, которые были приняты при концептуальном планировании.
в процессе опытной эксплуатации, когда уже все бизнес-процессы в новой системе описаны, роли настроены, модификации сделаны, инструкции выданы и надо просто начинать работать.
Проблема не в отсутствии этого этапа. Проблема в том, что на этапе опытной эксплуатации начинаются попытки переиграть те согласованные и закрепленные в регламентах решения, которые были приняты при концептуальном планировании.
Неприятие идеологии системы исполнителями: «Ваша система не заработает. У нас есть Алевтина Светозаровна – умнейшая женщина, 60 лет на заводе, все в голове держит, никакая система не учтет всего, что она помнит».
Как показывает практика, с умнейшими действительно полезно найти общий язык.
А у вас красной нитью — «мы пришли причинить вам счастье»
Беспощадно. Люто. Везде. Всегда…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Внедряя ERP на промышленных предприятиях: Алевтина Светозаровна и Excel против суровых архитекторов и английского завода