С т а т ь и Программисты и консультанты Ax
ПО ДАТАМ - ПО ЖУРНАЛАМ * ERP - УПРАВЛЕНИЕ - СИСТЕМЫ
- Подготовка проекта внедрения ERP
- Управление проектом внедрения ERP
- Эффективная эксплуатация и поддержка
Обсуждение на SQL ru
Скачать PDF статьи: Как сделать успешный ERP-проект
Статья опубликована в "Компьютерре" № 8 от 28.02.2006г. но на ее сайте нет иллюстраций.
С разрешения редации публикуем PDF с картинками:
Москва 2006г. Автор статьи: Мартынов Дмитрий. Автор илюстраций к статье ?? - художник Компьютерры.
Обсуждение статьи с сайта SQL ru
2.03.06 ax 18:10
У-М: Неплохая статья от компании внедряющей Axapta
Неплохая статья в свежей "Компьютерре" о типовых засадах при внедрении ERP От некой компании Koder Logic, внедряющей Axapta
Интересное у них видение проблемы. Пишут, что Исполнители заинтересованы большую часть денег срубить еще до внедрения (на предпроекте), а репутация никого не волнует, что кодеры - важнейшая роль во внедрении, и еще много такого необычного.
Кто-нибудь слышал проекты, где бы 90% бюджетных денег было выложено за предпроект?
Конь: За консалтинг основные бабки на учетных проектах
А что тут нового-то ? За консалтинг основные бабки и срубаются на учетных проектах. Азбучные истины.
FE: Сомнения по поводу качества статьи, хотя я и не читал
Что-то у меня возникают сомнения по поводу качества этой статьи, хотя я и не читал её... Люди, которые не умеют писать нрамотно даже у себя на сайте, вряд ли могут сказать что-либо умное...
Сисой: На внедрениях ERP основные бабки делаются ДО начала опытной эксплуатации
Да нет, статья и впрямь хорошая. Автор достаточно убедительно объясняет, почему, в частности, зарплата консультантов и аналитиков в массе своей выше зарплаты программистов. Именно потому, что на внедрениях ERP основные бабки делаются ДО начала опытной эксплуатации. Срубили бабло на впаривании шаблонов, а дальше хоть трава не расти.
gag: В сообществе ERP звание "программист" менее престижно, чем "консультант"
Выдержка из статьи:
- "В результате в сообществе ERP звание "программист" менее престижно, чем звание "консультант", несмотря на то что первая профессия изначально подразумевает более высокую квалификацию."
Да уж! Статья действительно, не плохая ;-)
Она - полностью непрофессиональная!
ИМХО - мягче тут не скажешь ;-((
softwarer: Обсуждать тезисы смысла не больше, чем искать истину анализом слоганов
Хм. Позволю себе не согласиться.
1. Обычный рекламный материал. Краткая суть: "все чмо, а вот мы - умные, добрые, хорошие и кстати совершенно случайно готовы оказать вот такие услуги". Целевая аудитория понятна.
2. Соответственно, обсуждать выдвинутые тезисы смысла не больше, нежели искать истину анализом слоганов. Они предназначены исключительно для воздействия.
3. Литературно статья не слишком профессиональна. Впрочем, не удивлюсь если это вполне осознанно, для большей близости потребителю.
4. Раз в пару лет я в таких ситуациях читаю Компьютерру именно чтобы убедиться, что ее по-прежнему совершенно незачем читать.
FE: Внедрение в корне меняет процессы управления - что менеджеры низшего звена ничего не подозревают?
Мда... Всё-таки я был прав - человек, не умеющий грамотно писать, вряд ли сможет сказать что-то умное. Или намеренно не говорит...
"В начале обследование, потом настройка системы и наконец внедрение. ... Последний и главный этап - собственно внедрение" - Внедрением называется весь процесс. Обследование и настройка точно так же входят во внедрение. Непонятно, что именно в таком контексте автор называет внедрением. Обучение пользователей? Ввод данных? Опытную эксплуатацию? По крайней мере, ясно, что это не обследование и не настройка.
"Это самая сложная часть, в которой и заключается суть проекта." - это не самая сложная часть.
"Если внедрение прошло удачно - даже при отсутствии предыдущих этапов (что, в принципе, возможно - есть примеры), то и весь проект будет успешным." - фигня. Точно так же я могу написать - "если опытная эксплуатация прошла удачно..." и далее по тексту.
"Поэтому все этапы до внедрения называют предпроектными работами." - простите, у кого они так называются? У Koder Logic? Так это не показатель.
"Все начинается с того, что руководство Заказчика принимает решение о начале проекта. В этот момент Исполнитель обычно еще не известен, и курировать проект начинает собственный специалист Заказчика. Его так и называют - Куратором проекта. " - боже ж мой... Могу только порадоваться за тех, кто работает с заказчиками, у которых до выбора системы есть куратор проекта! Обычно всё начинается со смутного беспокойства некоторых людей заказчика, которое потом уже может вылиться в попытку что-то выбрать.
"Он отвечает за формирование команды, которая подготовит проект, распланирует его и выберет исполнителя. " - нет в большинстве случаев такой команды! Нет ни плана проекта, ни подготовки. То, что описано в статье - идеальные, тепличные условия, о которых можно только мечтать!
"Введем упрощение. Будем считать, что невнедренный проект не влияет на репутацию Исполнителя. Это не совсем верно, но верно настолько, что мы можем это допустить" - ну, у кого репутации нет, для тех это верно. Для остальных это допущение в корне неправильно.
"Исполнитель знает, что составить такие описания бизнес-процессов и другую требуемую для проекта документацию, которую подпишет комиссия Заказчика, в общем-то нетрудно." - с чего это? Нет, конечно, если в "комиссию" набрать уборщиц, то, наверное, так и есть. Только вот нам на проектах всё больше попадаются въедливые и дотошные заказчики, у которых просто так ничего не подпишешь, и которые очень хорошо умеют считать деньги и хотят получить за них результат.
"Компетентные специалисты Заказчика не любят сбои в работе процесса, так как несут за них реальную ответственность. Если в описании БП такой сбой не будет описан, это произведет благоприятное впечатление на подсознательном уровне." - просто полный бред! Фрейд домашнего розлива...
"Техническое задание - это задание Заказчика Исполнителю. Не странно ли, что и его готовит Исполнитель? " - очень странно. Именно поэтому заказчик не оставляет этот процесс на самотёк. Конечно, в реальных проектах, а не в высосанных из пальца примерах.
Кстати, автор статьи Дмитрий Мартынов несколько лукавит - не доказав, что начальные документы не соответствуют потребностям проекта, в дальнейшем он принимает это как постулат. Кроме того, когда один документ готовится на основании другого, вовсе не факт, что ошибки первого перенесутся во второй документ, они, наоборот, могут быть исправлены.
"2.5. Обучение (свет в конце тоннеля)
Этап может принести большую пользу Заказчику в смысле контроля за подготовкой проекта." - простите, контроля за чем? За подготовкой проекта? Какая, в задницу, подготовка - проект идёт полным ходом!!!
"у Заказчика должна быть грамотная проектная команда, мотивированная на результаты проекта." - чуть ли не первая справедливая мысль. Впрочем, она настолько тривиальна, что даже стыдно такое читать.
"Когда будет выполнено все, кроме последнего этапа, нет гарантий, что полученная система сможет быть внедрена." - открою страшную тайну Дмитрию Мартынову - такой гарантии нет даже после того, как подписан акт и система должна начать работать. Гарантий нет вообще! И нет их не потому, что злобный и коварный исполнитель дурит наивного и простоватого заказчика, а потому, что на работоспособность системы влияет слишком много сторонних факторов.
"Для получения небольшой части оставшихся денег Исполнителю надо затратить солидные ресурсы и подключить квалифицированных специалистов, то есть внедрение для Исполнителя нерентабельно." - если так рассуждать, то вообще внедрением заниматься не надо. Вообще-то приличные фирмы подключают квалифицированных специалистов с начала проекта, и команда делает весь проект, в том числе и тот этап, который Дмитрий Мартынов загадочно называет "внедрением". Так что солидные ресурсы тратятся всегда, то есть, по логике Мартынова, нерентабельно всё внедрение в целом.
"Невыполнение обязательств по договору - тоже риск несущественный. Договор готовил Исполнитель и заранее продумал наличие в договоре лазеек для сложившейся ситуации." - вот так вот просто взял и отмёл этот риск! Несущественный, понимаете ли! Не надо считать заказчика неразумным ребёнком, он вполне понимает, за что платит деньги и что хочет получить в результате.
"Последний этап обычно очень сложен. Прежде всего из-за низкого качества выполнения задач предпроекта. " - это да, это правда. Если остальные этапы низкого качества, то загадочное "внедрение" Дмитрия Мартынова тоже будет низкого качества.
"Менеджеры нижнего звена порой не подозревают, что многое изменится, тогда как внедрение зачастую в корне меняет процессы управления. Это производит колоссальный эффект. Именно тогда представления о том, как и что должна уметь система, радикально меняются и доходят до руководства Заказчика. " - переведите кто-нибудь эту фразу!!! То есть менеджеры низшего звена ничего не подозревают, потом резко меняются процессы управления, и потом это всё доходит до высшего руководства?!? Блин, это ж надо такую чушь написать!
"В результате в сообществе ERP звание "программист" менее престижно, чем звание "консультант", несмотря на то что первая профессия изначально подразумевает более высокую квалификацию." - вообще-то это неправда. С какой стати программист подразумевает более высокую квалификацию?
Да, кстати. Чуть выше в статье автор говорит, что "Риск потери репутации отсутствует - мы ввели такое допущение (почему, объясняется в разделе "Итоги не для всех"). " Так вот, нет в этом разделе никаких объяснений.
"Один из вариантов повлиять на качество предпроектных работ (описание бизнес-процессов, техническое задание) - это заключать на них отдельные договора с Исполнителем." - да?!? Правда?!? Это снижает риск?!? Если следовать предыдущим рассуждениям автора, то исполнитель кое-как малыми силами делает описание, быстренько его сдаёт, получает деньги и ищет следующий проект. Маржа будет достаточно высокой, ответственности никакой, а заказчик остаётся с ненужным ему описанием бизнес-процессов и идёт искать следующего исполнителя, чтобы снова заплатить ему за то же самое. Офигенное снижение риска! :D
Прощу прощения за столь обильное цитирование, но, честное слово, эта статья не может оставаться без отклика. Такими "статьями" они просто сами себе копают яму, и да чёрт бы с ними, но ведь люди могут подумать, что и другие фирмы так делают!
И они ещё говорят, что они внедряют Axapta! Сделали два с половиной проекта, и теперь начинают учить других...
Сисой: Большинство менеджеров считает "внедрением" что-то вроде опытной эксплуатации
Уважаемый FE!
Если Вам так хочется обозвать автора статьи кретином, то так и сделайте еще раз! Но не надо переносить свой субъективный опыт на все внедрения!
Во-первых, Компьютерра - журнал для широкого круга читателей, а не для консультантов по ИТ. Сотношение примерно как у "Популярной механики" и квантовой физики. И в подобной статье вполне допустима подмена понятий.
Большинство менеджеров считает "внедрением" что-то вроде опытной эксплуатации, а Обследование, Настройка - это вне их восприятия. Если автор статьи вводит такую классификацию этапов - его право. Будь это Энтерпрайз Мэгезин - я бы тоже возмутился.
Я неоднократно встречался на реальных проектах со всем тем, что пишет автор статьи. В том числе и с Кураторами, выбирающими системы. Вот, к примеру, текущий проект - именно такой. И фирм, заваливающих проекты к концу этапа Дизайна - полно.
Насчет консультанта и программиста. Обратите внимание на слово "изначально". Смысл его в том, что начинающий консультант - это переквалифицировавшийся из любой смежной области специалист, в вузах "консультантов" не готовят. В то же время занятие программироваием (на уровне кодера в ERP) требует как минимум предшествующей практики и обучения.
Лично я не соглашусь разве что с полезностью выделения предпроцесов в отдельные договоры. Ни к чему это.
FE: Я не сталкивался с менеджером, который бы под "внедрением" понимал что-то вроде опытной эксплуатации
Сисой, не могу с Вами согласиться.
Вот как раз я не переношу свой опыт на все внедрения, поэтому и не говорю, что "бывает так, и не иначе", в отличие от безаппеляционной манеры автора статьи.
Большинство менеджеров считает "внедрением" что-то вроде опытной эксплуатации, а Обследование, Настройка - это вне их восприятия.
Тоже не согласен. По моему опыту, это совсем не так. Более того, я лично ни разу не сталкивался с менеджером, который бы под "внедрением" понимал что-то вроде опытной эксплуатации. Конечно, вводить классификацию - право автора, но:
1. Желательно, чтобы она соответствовала общепринятой;
2. В случае отклонения желательно иметь обоснование отклонения и определения.
Автор изменяет устоявшиеся термины и не даёт никакх пояснений.
А вот подмена понятий недопустима! Упрощение - да, но до тех пор, пока оно не приводит к неверным результатам. Выводы же автора неверны в корне.
Я неоднократно встречался на реальных проектах со всем тем, что пишет автор статьи. В том числе и с Кураторами, выбирающими системы. Вот, к примеру, текущий проект - именно такой.
Охотно верю. Только отвечу Вам Вашими же словами: "не надо переносить свой субъективный опыт на все внедрения". Надеюсь, Вы не будете утверждать, что всегда и везде до выбора системы создаётся будущая группа проекта во главе с куратором?
mal_ora: Консультант - человек с опытом, знающий проблематику предпредприятия где происходит внедрение
|
Сисой Смысл его в том, что начинающий консультант - это переквалифицировавшийся из любой смежной области специалист, в вузах "консультантов" не готовят. |
Почти согласен, но отмечу что каждый должен быть проффесионален.
Крайности: Программист
1. Кодер, набывает код по разжованому до подробностей заданию (теоритически может и студент).
2. Проэктировщик развивает ERP в нужном направлении. Опытный, умеющий ставить и решать крупные задачи.
Консультант
1. Белозубая улыбка, фразы типа потянет, не потянет. (тут важно умение "пихать")
2. Человек с опытом, знающий проблематику предпредприятия, где происходит внедрение (даже лучше заказщика) предлагающий реальные способы решения проблем.
P.S. не претендую на идеальность формулировок, просто хочу подчеркнуть то что не надо спорить кто круче (это разные проффесии), согласен консультантов в вузах не готовят. Но консультантов типа 2 как и "программистов" типа 2 не так легко найти.
softwarer: Хорошие консультанты встречаются куда реже хороших программистов
По моему весьма невеликому опыту, хорошие консультанты встречаются куда реже хороших программистов. Может быть именно потому, что их нигде не готовят и никогда не готовили; может быть, по другим причинам.
iscrafm: Пока консультанты с умным видом крошат внутренности Axapta - это не внедрение
|
ВНЕДРЕНИЕ — распространение нововведений, достижение практического использования прогрессивных идей,изобретений, результатов научных исследований. |
Пока консультанты с умным видом проводят интервью пользователей, пишут нужные только им бумаги, крошат внутренности Axapta - это не внедрение.
Самое тяжелое начинается (и автор статьи абсолютно прав) в тот момент, когда к системе подпускают ее настоящих пользователей и они начинают пытаться работать с тем, что придумали консультанты и сделали программисты. Это и называется внедрением.
locky: Кодера я могу натаскать за 3-6 месяцев, консультанта или спеца по обследованию ???
|
softwarer По моему весьма невеликому опыту, хорошие консультанты встречаются куда реже хороших программистов. Может быть именно потому, что их нигде не готовят и никогда не готовили; может быть, по другим причинам. |
Нормального кодера я могу натаскать где-то за 3-6 месяцев, а нормального консультанта или спеца по обследованию... боюсь, и сам я в этой ипостаси дааааалёк от хорошего показателя...
FE: Внедрением называется весь проект, от начала обследования до сдачи в промышленную эксплуатацию
iscrafm, Вы привели выдержку из словаря? Так она в данном случае бесполезна, потому что существуют устоявшиеся в отрасли термины. Внедрением называется весь проект, от начала обследования до сдачи в промышленную эксплуатацию. Так что то, что автор называет "внедрением" - это отнюдь не самая тяжёлая часть.
Нет, не спорю, для каких-то фирм, возможно, это и правда, всё зависит от методологии внедрения. Только вот я бы на месте заказчика не связывался с фирмами, у которых такая методология.
И ещё почему я так резко реагирую на статью - если бы Дмитрий Мартынов написал "мы делаем вот так, и у нас возникают такие проблемы", то я бы просто посмеялся над статьёй и занёс в архив курьёзов. Однако он начинает строить обобщения, вот в чём беда!
Согласен с gag - статья полностью непрофессиональная.
iscrafm: В какой отрасли обследование не считается внедрением?
FE, Вы о какой отрасли говорите? В той что я работаю, обследование не считается внедрением.
|
Сисой Смысл его в том, что начинающий консультант - это переквалифицировавшийся из любой смежной области специалист, в вузах "консультантов" не готовят. |
Я бы тоже не советовал связываться с конторами, которые внедрением считают решение собственных проблем. Методология, о которой Вы упоминаете, позволяет раскрутить заказчика на большую сумму с меньшими потерями для себя, а речь идет о том, чтобы система заработала.
softwarer: Для внедрения ERP "нормальный кодер" полезнее "хорошего программиста"
locky
Нормального кодера я могу натаскать где-то за 3-6 месяцев, а нормального консультанта или спеца по обследованию... боюсь, и сам я в этой ипостаси дааааалёк от хорошего показателя... |
Хм. Между нормальным кодером и хорошим программистом - бооольшая разница. Хотя я согласен с тем, что для идеального внедрения ERP "нормальный кодер" намного полезнее "хорошего программиста".
Собственно, консультанты, которых я встречал, в основном как раз и производят впечатление натасканных за 3-6 месяцев и ничуть не поднявшихся в уровне с тех пор.
FE: Я об отрасли внедрения информационных систем класса ERP. Там обследование - часть внедрения, это у SAP, у Oracle, у Axapta
iscrafm, я говорю об отрасли внедрения информационных систем класса ERP. Там обследование является частью внедрения, это есть и у SAP, и у Oracle, и у Axapta.
|
iscrafm Методология, о которой Вы упоминаете, позволяет раскрутить заказчика на большую сумму с меньшими потерями для себя, а речь идет о том, чтобы система заработала. |
Я не упоминаю ни о какой конкретной методологии. Впрочем, предположим, что имеется ввиду что-то конкретное.
- Правильно ли я понимаю, что Вы согласны целиком или по большей части с обсуждаемой статьёй?
- Правильно ли я понимаю, что Вы готовы защищать статью?
- Правильно ли я понимаю, что Вы обвиняете все компании, которые занимаются внедрением и не придерживаются точки зрения автора статьи, в выкачивании денег?
С той статьёй с некоторыми оговорками я могу согласиться - да, так бывает. Совет только один - не связывайтесь с такими ИТ-компаниями.
iscrafm: Автор считает, что внедрение - это установка адаптированного к предприятию продукта и его опытная эксплуатация
|
FE iscrafm, я говорю об отрасли внедрения информационных систем класса ERP. Там обследование является частью внедрения, это есть и у SAP, и у Oracle, и у Axapta. |
FE, это все игра слов. Вы переводите implementation как внедрение - пожалуйста. Definitions, Operations Analisis (в AIM) или Project Preparations в ASAP как обследование - тоже нет возражений. Автор считает, что внедрение - это установка уже адаптированного к предприятию продукта и его опытная эксплуатация. Я тоже так считаю. ASAP считает что это Go Live & Support, AIM - Transition - > Production. Договора заключают как на внедрение, так и на создание "комплексной информационной системы", этапами которого могут являться обследование и документирование бизнес-процессов (Bussines Blueprint в ASAP, Operations Analisis в AIM), разработка решения (Realization в ASAP, Solution Design & Build в AIM), внедрение решения (запуск в эксплуатацию, обучение, тестирование). По крайней мере автор не исказил смысла. А какими терминами Вы более привыкли оперировать - это личные предпочтения. Если сюда приплести TARGET и всю остальную братию, их появится еще больше.
|
FE - Правильно ли я понимаю, что Вы согласны целиком или по большей части с обсуждаемой статьёй? |
|
FE - Правильно ли я понимаю, что Вы обвиняете все компании, которые занимаются внедрением и не придерживаются точки зрения автора статьи, в выкачивании денег? |
Нет. Я говорю только о том, что много проектов умирают именно на стадии внедрения в понимании автора. Зато с рапортом о завершении внедрения :)
FE: Насколько трудоёмко "внедрение", если предыдущие этапы выполнены качественно?
|
iscrafm Автор считает, что внедрение - это установка уже адаптированного к предприятию продукта и его опытная эксплуатация. |
Во-первых, нигде в статье данного определения нет. Во-вторых, дело не в игре словами, а в общепринятых терминах. Если хотите менять их - пожалуйста, только желательно дать определение и обосновать необходимость изменения понятий. На самом деле, это уже вторично, я готов принять Ваше определение внедрения (жаль, правда, что Мартынов ничего не написал по этому поводу).
|
iscrafm Нет. Я говорю только о том, что много проектов умирают именно на стадии внедрения в понимании автора. Зато с рапортом о завершении внедрения :) |
Это хорошо, что Вы не бросаетесь обвинениями, приятно слышать разумного человека. Не могу не согласиться с Вашим высказыванием. Правда, могу добавить, что много проектов умирают и после "внедрения" в понимании Мартынова, и тоже с рапортами.
Теперь по статье. iscrafm, Вы согласны с допущением, что компании-внедренцы не заботятся о своей репутации? Заметьте, не некоторые, а все.
Второй вопрос - как Вы полагаете, iscrafm, насколько трудоёмко "внедрение" Мартынова, если предыдущие этапы выполнены качественно?
Третий вопрос - как Вы можете объяснить пассаж по поводу "невыгодности внедрения", а именно то, что необходимо привлекать квалифицированных специалистов? Согласны ли Вы в этом с Мартныновым, или же полагаете, что квалифицированных специалистов необходимо привлекать с самого начала проекта?
iscrafm: Даже при детальном ТЗ на этапе запуска системы созданной по ТЗ могут возникнуть трудности
|
FE iscrafm, Вы согласны с допущением, что компании-внедренцы не заботятся о своей репутации? Заметьте, не некоторые, а все. |
Не нашел такого в статье. Есть допущение "Введем упрощение. Будем считать, что невнедренный проект не влияет на репутацию Исполнителя. Это не совсем верно, но верно настолько, что мы можем это допустить...."
Тяжело себе представить компанию, которая не заботится о своей репутации. Гудвил - тоже актив, правда за деньги его не купишь, его нужно заработать.
В статье есть еще такое: "В конечном счете Исполнителю доверяется и выполнять проект, и контролировать его выполнение. Иными словами, ему поручается следить за самим собой." Это вполне реальная ситуация. Не сталкивались? Видимо из этого и принимается допущение указанное выше.
|
FE Второй вопрос - как Вы полагаете, iscrafm, насколько трудоёмко "внедрение" Мартынова, если предыдущие этапы выполнены качественно? |
Возможно очень трудоемко, но не зная конкретой ситуации сказать тяжело. Но то, что даже при детально расписанном ТЗ на этапе запуска созданной по ТЗ системы могут возникнуть, мягко говоря, трудности - это реально. Мы, например, бывает запускаем систему в режиме "горячей замены" и сталкиваемся с такими особенностями, которые не пропишешь в ТЗ, как не старайся. Просто их не видно, пока некоторое время пользователи не поработают и не повылезают разные "тараканы". Здесь возможны 2 варианта:
1. Заказчик сам дурак, ТЗ же подписывал, будь добр подпиши и акт выполненных работ по ТЗ
2. Сделать так, чтобы система все же заработала, пусть даже с отклонениями от утвержденного ТЗ. И здесь опять всплывает вопрос о репутации.
|
FE Согласны ли Вы в этом с Мартыновым, или же полагаете, что квалифицированных специалистов необходимо привлекать с самого начала проекта? |
На проект в принципе нужно привлекать квалифицированных специалистов. Считаю, что вопрос на каком этапе - просто неуместен.
FE: Грамотное описание бизнес-процессов и грамотное проектирование системы - залог успешной эксплуатации, как опытной, так и промышленной
Вот видите, iscrafm, Вы тоже согласны, что компании заботятся о своей репутации. Вся же статья написана в том предположении, что этого нет.
"Это не совсем верно, но верно настолько, что мы можем это допустить...."
С ситуацией, когда исполнитель сам контролирует проект, лично не сталкивался. Видимо, нам попадаются более строгие и придирчивые заказчики. Поэтому делать допущение такое и строить на нём всю статью категорически нельзя.
|
iscrafm Мы, например, бывает запускаем систему в режиме "горячей замены" и сталкиваемся с такими особенностями, которые не пропишешь в ТЗ, как не старайся. Просто их не видно, пока некоторое время пользователи не поработают и не повылезают разные "тараканы". |
Согласен. Только ведь это именно особенности, а не кардинальная перестройка всех процессов по-новому, верно? Таким образом, получается, что грамотное описание бизнес-процессов и грамотное проектирование системы - залог успешной эксплуатации, как опытной, так и промышленной.
iscrafm: Стараемся заработать прибыль и репутацию одновременно
Если я правильно понял смысл статьи, то он заключается в том, чтобы показать в первой части на какие грабли можно наступить, а в конце - как их избежать. Причем аппелирует автор - к заказчикам. Может Вы вычитали что-то между строк и я этого не вижу?
|
FE Как же Вы работаете, хочется спросить? |
Стараемся заработать прибыль и репутацию. Одновременно. А Вы разве не так? :)
FE: Рекомендации, которые даёт автор, тривиальны
iscrafm, в том-то и дело, что перечисленных граблей легко избежать, и наступать на них могут только те, кто совсем не умеет работать! Кроме того, перечисленные грабли возникают при совершенно невероятном стечении обстоятельств. Утверждать (как это делается в статье), что такие случаи типичны, я бы не рискнул. А уж рекомендации, которые даёт автор, настолько тривиальны, что просто стыдно их читать.
iscrafm: Внедрение ERP - не является основным видом деятельности заказчиков
Заказчики все разные. Кто умеет работать, а кто и нет в этом направлении. Внедрение ERP - не является их основным видом деятельности . Поэтому я бы все таки по мягче с обвинениями их в неумении работать.
Сисой: В ГОСТ-34 термина "внедрение" вообще нет
|
FE iscrafm, Вы привели выдержку из словаря? Так она в данном случае бесполезна, потому что существуют устоявшиеся в отрасли термины. Внедрением называется весь проект, от начала обследования до сдачи в промышленную эксплуатацию. Так что то, что автор называет "внедрением" - это отнюдь не самая тяжёлая часть. |
В данной отрасли никаких устоявшихся терминов не существует. Термины, может и устоялись в головах знатоков ASAP или AIM, но не надо переносить свои формулировки (тем более, отягощенные спецификой перевода) на всю отрасль. Единственный документ, хоть как-то дающий в России предписание всей отрасли - ГОСТ-34:
Стадии - Этапы работ
1. Формирование требований к АС 1.1. Обследование объекта и обоснование необходимости создания АС. 1.2. Формирование требований пользователя к АС. 1.3. Оформление отчёта о выполненной работе и заявки на разработку АС (тактико-технического задания)
2. Разработка концепции АС. 2.1. Изучение объекта. 2.2. Проведение необходимых научно-исследовательских работ. 2.3. Разработка вариантов концепции АС, удовлетворяющего требованиям пользователя. 2.4. Оформление отчёта о выполненной работе.
3. Техническое задание. 3.1. Разработка и утверждение технического задания на создание АС.
4. Эскизный проект. 4.1. Разработка предварительных проектных решений по системе и её частям. 4.2. Разработка документации на АС и её части.
5. Технический проект. 5.1. Разработка проектных решений по системе и её частям. 5.2. Разработка документации на АС и её части. 5.3. Разработка и оформление документации на поставку изделий для комплектования АС и (или) технических требований (технических заданий) на их разработку. 5.4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации.
6. Рабочая документация. 6.1. Разработка рабочей документации на систему и её части. 6.2. Разработка или адаптация программ.
7. Ввод в действие. 7.1. Подготовка объекта автоматизации к вводу АС в действие. 7.2. Подготовка персонала. 7.3. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями). 7.4. Строительно-монтажные работы. 7.5. Пусконаладочные работы. 7.6. Проведение предварительных испытаний. 7.7. Проведение опытной эксплуатации. 7.8. Проведение приёмочных испытаний.
8. Сопровождение АС 8.1. Выполнение работ в соответствии с гарантийными обязательствами. 8.2. Послегарантийное обслуживание
Но здесь термина "внедрение" вообще нет. Поэтому давайте не будем цепляться к словам.
FE: Под "внедрением" понимается процесс в целом, а не этапы обучения пользователей и опытной эксплуатации
Сисой, есть термины, которые понимаются большинством компаний одинаково. Нет юридического документа, закрепляющего эти понятия, но есть практика работы. Так вот, Вы не хуже меня знаете, что и ASAP, и ON TARGET понимают под внедрением. Более того, если Вы будете общаться с представителем мало-мальски крупной компании (IBS, TopsBI, SAP, BDO, Корус, Columbus, GMCS, АНД, et cetera...), то под "внедрением" будет пониматься процесс в целом, а не этапы обучения пользователей и опытной эксплуатации.
Спорить по этому поводу я не вижу смысла, потому что здесь переубедить меня врядли удастся. Как я уже говорил выше, если автор хочет дать своё определение - ради бога, только нужно само определение и обоснование. Предлагаю вернуться к обсуждению статьи, а не "придираться к словам", как Вы справедливо заметили.
iscrafm, моё замечание о неумении работать относилось в основном к исполнителям, а не к заказчикам. Впрочем, Вы ведь согласны с тем, что заказчики разные, и не стремитесь обобщить положения статьи на всех. Именно об этом я и говорю - не стоит личный опыт обобщать на всех, да ещё опыт, свидетельствующий о странных (мягко говоря) подходах к внедрению.
IgorM: Неудачных внедрений (с точки зрения заказчика), я наблюдал больше, чем удачных
FE, скажите, Вы работаете в компании-внедренце? А может быть даже конкуренты автора статьи?
Это к тому, что я, как разработчик заказчика, видел описанный автором процесс внедрения. И, к сожалению, не один. Не буду говорить про типичность, но с Вашим утверждением что "...перечисленные грабли возникают при совершенно невероятном стечении обстоятельств." не согласен совершенно. О неудачных внедрениях (с точки зрения заказчика), я слышал (и наблюдал) больше, чем о полностью удачных и причины были аналогичны.
FE: Нормальные компании так не внедряют
Да, я работаю в компании-внедренце. Только вот Koder Logic для нас не конкуренты, они слишком маленькие.
Про неудачные внедрения не спорю, их есть, только проблемы там возникают совсем не так, как описано в статье. И совет только один - не связывайтесь с компаниями, которые внедряют описанным в статье способом. Скажу более - нормальные компании так не внедряют.
Сисой: Однозначного подхода к внедрениям нет. Интегратор делит проекты на "референтные" и "второстепенные"
Да, он по ту сторону баррикад. А мы - по эту. Поэтому мы и видим, как нас обувают... :-)
А если серьезно, то однозначного подхода к внедрениям нет. Одна и та же крупная компания может делить текущие проекты на "референтные" и "второстепенные". На первых - делают имя и стараются угодить Заказчику, на вторые - посылают стажеров и стараются побыстрее вытянуть деньги и отмахнуться.
FE: В статье частный опыт автора переносится на все внедрения
Сисой, мне жаль, что у Вас такой подход. Я никогда не воспринимал заказчика как противника, я всегда стараюсь воспринимать его как партнёра. Скажите, когда Вы внедряли (если я не ошибаюсь), Вы (как в статье сказано) стремились по-быстрому сорвать деньги, плевали на репутацию, подсовывали заказчику стажёров, делили проекты на референсные и второстепенные? На Ваш взгляд, к примеру, Сергей Мазуркин так поступает?
Впрочем, мы сейчас обсуждаем не внедренческие фирмы в целом, а конкретную статью. Так вот, на мой взгляд, статья глупая, потому что основана на неверных предпосылках - раз, переносит частный опыт автора на все внедрения - два, и заканчивается или тривиальными, или неверными рекомендациями - три.
Сисой: Я знаю компании, внедряющие продукты MBS таким образом. Причем это не от системы зависит - так можно внедрять и 1С и SAP
FE
Сисой, мне жаль, что у Вас такой подход. Я никогда не воспринимал заказчика как противника, я всегда стараюсь воспринимать его как партнёра. Скажите, когда Вы внедряли (если я не ошибаюсь), Вы (как в статье сказано) стремились по-быстрому сорвать деньги, плевали на репутацию, подсовывали заказчику стажёров, делили проекты на референсные и второстепенные? На Ваш взгляд, к примеру, Сергей Мазуркин так поступает? |
Обратите внимание, что я снабдил свою фразу смайликом, т.е. это всего лишь ирония. Когда я внедрял, я не мог определять подход к Заказчику. Это делали, как правило, собственники бизнеса, а не РП. И это одна из причин, почему я больше не хочу работать в консалтинговых и внедренческих конторах. Бизнес есть бизнес, аппетиты хозяев растут, и вот уже нормальный, рабочий подход к клиенту сменяется бизнес-моделью выкачивания денег. К уважаемому mazzy это не относится, но я знаю не одну и даже не две компании, внедряющие продукты MBS таким образом. Причем это не от системы зависит - так можно внедрять и 1С и SAP. У этой темной стороны жизни есть еще один аспект.
Жуткие переработки консультантов на проектах в попытке спасти изначально "списанный" руководством проект. "Стокгольмский синдром" единства консультантов и Заказчика. Кто внедрял - поймет, о чем я. Можно еще раз опусы Сысовской перечитать.
С точки зрения Заказчика бороться с таким подходом можно, в частности, путем выделения отраслевых центров компетенции по внедрению. Если внедрять ERP в этой отрасли будет только один (максимум 2) партнер(а), его внедрения легко можно проверить. А выбирать из 20 мелких контор, у каждой из которых 2-3 проекта, проблематично.
Кстати, сейчас у нас хорошие Исполнители. И к ним особых претензий нет. Но у нас "референтное" внедрение, первое в этой отрасли :-)
IgorM: Если не брать во внимание миллионные проекты, то широкого распространения информации о неудачном внедрении обычно не бывает
|
FE - неверно допущение, что внедренцы не заботятся о своей репутации; - неверен взгляд, что главным обязательно является этап опытной эксплуатации ("Внедрение" в терминологии Мартынова); - неверно допущение, что заказчик смотрит сквозь пальцы на качество предоставляемых ему документов; - неверно предположение о том, что "плохие" документы первых этапов не могут быть исправлены в последующем; |
По поводу репутации: на мой взгляд допущение верно. Если не брать во внимание миллионные проекты, то широкого распространения информации о неудачном внедрении (что, как я понимаю, и ведет к снижению репутации) обычно не бывает: а) потому что сам исполнитель не афиширует это, по вполне понятным причинам; б) потому что заказчик к такой рекламе тоже не склонен; в) величина рынка средних проектов (тысячи и сотни тысяч долларов), на мой взгляд, достаточно велика. Эти было сказано и Мартыновым.
По поводу опытной эксплуатации: Почему? С точки зрения заказчика, если система не эксплуатируется, то проект неудачный. Иначе зачем всё затевалось?
По поводу документов: Не увидел этого в статье. Что касается тезиса автора о том, что заказчик НЕ ВСЕГДА может верно ОЦЕНИТЬ качество документов - согласен. По тем же причинам: в штате заказчика может и не быть специалистов нужной квалификации.
Не "не могут быть исправлены", а обычно "не исправляются". Причины автором описаны, на мой взгляд, верно.
Валентин К: Автор частично прав. Он смотрит со стороны заказчика, а не внедренца и консультанта
Я считаю, что автор статьи частично прав, причем смотрит он в большей части статьи со стороны заказчика, а не внедренца, консультанта, вобщем исполнителя. Это его характеризует не как теоретика, а как внедренца, который смог таки смотреть более-менее объективно.
Мое мнение тоже субъективно. Но глубокого антагонизма статья для меня не вызвала. Я работал с различными заказчиками, причем никто из них толком не знал, что же ему хочется.
Кстати напомню, что при реализации пректа по сроку 6-12 месяцев всегда происходят изменения, которыми нужно управлять на уровне проекта. Если этого не делать - он может развалиться, причем будет куча мнений, но объективное мнение будет такое - никто не знает почему.
Сразу прокомментирую: Почему не достигнут результат, а не почему развалился проект. Это на самом деле не одно и тоже.
Поиск причины неудавшейся цели отличается от поиска крайних для пинка.
FE: Этап опытной эксплуатации является не главным, успех или неудача проекта закладываются на более ранних этапах
- информация о неудачном внедрении распространяется достаточно быстро. Пусть официально об этом не объявляют, но заказчик об этом рассказывает. Имел возможность убедиться неоднократно. Кроме того, рынок не так уж и велик, все друг друга знают. Разумеется, информация о неудачном внедрении в холдинге "Объединённые ларьки у метро Алтуфьево" долго не будет известна, но мы же говори о более-менее крупных проектах?
- этап опытной эксплуатации является не главным, потому что успех или неудача проекта закладываются на более ранних этапах. Проект может быть неудачным даже после официального завершения опытной. Примеры, к сожалению, не имею права приводить, но их есть у меня.
- Оценка заказчиком качества документов - смотрим разделы статьи 2.1, 2.2 (второй абзац). В дальнейшем то, что документы не соответствуют потребностям проекта, принимается как данность (раздел 2.3, второй абзац, раздел 2.7, первый абзац). Это неверно потому, что
а) Далеко не каждый заказчик невнимательно читает документы; б) "плохой" документ на первом этапе может быть исправлен на последующих.
В статье подобные проблемы приводятся как типичные и характерные, хотя мой личный опыт говорит об обратном.
- Привлечение квалифицированных специалистов. Раздел 2.6, предпоследний абзац, цитирую: "Для получения небольшой части оставшихся денег Исполнителю надо затратить солидные ресурсы и подключить квалифицированных специалистов, то есть внедрение для Исполнителя нерентабельно."
Из этого я делаю вывод, что, раз квалифицированных специалистов надо подключать на этом этапе, то ранее они не подключались. Кроме того, это подтверждается словами автора "... то есть внедрение [при использовании квалифицированных специалистов] для Исполнителя нерентабельно". Таким образом, следуя логике автора, при использовании квалифицированных специалистов весь проект не может быть рентабельным. Это противоречит действительности.
- риски, Вы совершенно правы, действительно не возникают потому, что их обходят. Достаточно всего лишь заказчику быть внимательным к документам, а исполнителю хорошо готовить эти документы и хорошо работать с самого начала, и тогда этап опытной эксплуатации проходит как по маслу, и все довольны! ;-)
- почему не нужен отдельный договор на каждый этап (а не на описание БП), я уже писал.
- внешние консультанты... Вы знете, если это будут аудиторы из большой четвёрки, я, пожалуй, признаю их полезность. Только для заказчика это будет очень дорого стоить. ;-)
- Раздел 3.2... Вы знаете, эта рекомендация не приведёт ни к каким последствиям. Просто, если дело дойдёт до суда (крайний случай), заказчик честно может заявить - "да, качество отвечает потребностям". И что заказчик будет делать дальше в суде? Опять говорить "А мы имели ввиду вот это"?
Обезопасить себя от некачественного проектирования таким способом невозможно, поэтому рекомендация глупая.
Именно поэтому я и не пишу статьи, потому что мой личный опыт не позволяет сделать обобщения, я прекрасно понимаю, что все ситуации в проектах мне не охватить.
Упреждая вопрос - опыт не позволяет обобщить, но вот опровергнуть обобщение - для этого достаточно иметь опыт хотя бы по одному проекту.
Я полагаю, что подобные статьи можно писать на основании серьёзных исследований, в том числе и статистических, но никак не на основании двух сделанных проектов.
- уверенности в том, что заказчик сможет правильно выбрать компанию, у меня нет. Гарантии здесь дать невозможно, можно только оперировать вероятностью.
Garya: В ТЗ написана фраза "программа должна формировать калькуляцию фактической себестоимости продукции"
Хочу поддержать FE в некоторых сделанных им выводах, дополнив собственными соображениями.
В документе большой акцент делается на составление разного рода документов - договоров, соглашений, актов. С одной стороны может показаться, что грамотное их составление позволяет уберечь себя (не важно, с какой стороны от этого документа это "себя" находится) от каких-то серьезных проблем, однако это не совсем так. Потому, как такие проекты, как класс задач, не на 100% систематизируемы. В частности, даже супер-пупер-грамотно составленное ТЗ никогда не сможет охватить всех аспектов и нюансов, с помощью которых исполнителя можно заставить помимо его воли в будущем делать то, чего он делать не хочет. Где-то когда-то пример я уже приводил - про мониторы. В ТЗ нет никаких указаний, на каких видеомониторах должна отображаться информация. Следовательно, она может быть отображена, например, с помощью 100-ваттной лампочки, и при этом все сказанное в ТЗ попадает под ограничения, накладываемые этим видом отображения. Это заведомо скандальный пример просто иллюстрирует, что абсолютно всё в ТЗ предусмотреть в принципе невозможно, будучи даже 333 пядей во лбу.
Потому успешность реализации проекта зависит не только и не столько от качества составления документов и в какой последовательности выполняются телодвижения, сколько от изначального настроя сторон (добровольного и добросовестного желания) решить задачу. Если у одной из сторон такого желания нет, никакие танцы с бубном, обращения в суд и т.д. и т.п. не помогут. Защищающийся в суде имеет примерно 10-кратное преимущество по отношению к нападающему (говорю это как человек, имеющий подобный опыт). Потому как защищающий может потребовать доказательства по любому слову, по любой фразе, любой формулировке, уазанной в обвинении - и истец обязан их предоставить. Не доказав всего одно из своих утверждений, истец получит от суда отлуп. Ответчику же ничего доказывать не требуется - потому как он просто обороняется. Исходя из "презумпции невиновности" доказывать виновность должен обвиняющий, обороняющейся стороне не требуется доказывать свою невиновность - она предполагается изначально.
По многим вопросам, имеющих отношение к IT, есть "общие представления", на каждое из которых имеются пусть и малочисленные, но контр-мнения. Защищающейся стороне достаточно привести ссылку хотя бы на одно такое мнение, пусть и не солидное, пусть и редкое, пусть и безграмотное (с точки зрения большинства специалистов), чтобы суд формально признал правоту защищающейся стороны - в области, в которой нет на 100% единого мнения, стандарта по какому-либо вопросу, любое положение или высказывание может быть юридически весьма успешно оспорено.
И еще раз о ТЗ. На самом деле попытка отобразить в ТЗ все мелочи реализации - на несколько порядков более трудоемка, нежели сама реализация. Нет никакого смысла заказчику писать или проверять все детали такого документа, потому как гораздо проще просто взять и реализовать все перечисленные в нем требования.
Возьмем тривиальный пример. В ТЗ написана фраза "программа должна формировать калькуляцию фактической себестоимости продукции". Однако, не указано, какой именно продукции. С формальной точки зрения исполнителю достаточно реализовать показ картинки (скриншота) с один раз когда-нибудь произведенного расчета калькуляции. Доказать, что подразумевался расчет калькуляции продукции ЛЮБОЙ, которую возмьется производить предприятие (даже в будущем, даже совершенно по другим технологиям и использующим другие принципы формирования косвенных расходов) будет практически невозможно.
К чему это я всё говорю? Просто пытаюсь констатировать факт. Доверять нужно только тем внедренцам, которые могут показать множество уже реализованных проектов, заказчики которых остались довольны. Тех, которые дорожат прежде всего своей репутацией. Всё остальное - вода... :)
СофтDeveloper: Почему при внедрении ERP никто не пользуется Agile методами по ведению проектов аналогично любому софт. проекту
Во многом cогласен с Garya.
Что меня удивляет - почему при внедрении ERP никто не пользуется Agile методами по ведению проектов аналогично любому софт. проекту? Ведь ясно же, что:
1. Ни одно ТЗ не опишет 100% конечных требований (даже если опишет на начальном этапе - скорее всего сами требования изменятся)
2. Заказчик не в состоянии сразу правильно сформулировать конечные требования - в этом автор статьи абсолютно прав:
|
FE "Менеджеры нижнего звена порой не подозревают, что многое изменится, тогда как внедрение зачастую в корне меняет процессы управления. Это производит колоссальный эффект. Именно тогда представления о том, как и что должна уметь система, радикально меняются и доходят до руководства Заказчика. " - переведите кто-нибудь эту фразу!!! То есть менеджеры низшего звена ничего не подозревают, потом резко меняются процессы управления, и потом это всё доходит до высшего руководства?!? Блин, это ж надо такую чушь написать! |
Дорогой FE, это не чушь. Когда человек (менеджеры нижнего звена - не аналитики, продумывающие все на 3 шага вперед) на бумаге читает описание процесса, он не всегда его проектирует на свою ежедневную деятельность и может упустить ньюансы, которые потом приведут к переделке всего процесса и/или других, зависящих от него.
Ведь когда приглашают внедрять новую систему - это означает (опустим случаи, когда просто нужно бюджет освоить с откатами), что в компании есть участки деятельности, где автоматизации либо нет, либо она совсем кривая. Взять такой один участок, написать use-cases для основных случаев, реализоавать это и показать Заказчику. Сразу всплывут и будущие недовольства интерфейсом и все РЕАЛЬНЫЕ проблемы и тонкости, которые на бумаге отсуствуют. И так можно постепенно имплементировать все процессы, с постоянным отзывом от будущих пользователей - это гарантирует, что уже сделанные модули выполнены с приемлемым качеством и соответствуют требованиям Заказчика.
Как все внедряется сейчас - сначала будем до посинения писать документы и надувать щеки, протягивая гордую визитку "Аналитик", а потом 50% из этого будем переписывать, либо еще хуже - сделаем по другому, а документацию оставим старую - это называется Waterfall подход, при котором любой крупный софт. проект может провалиться с большой вероятностью.
Лично у меня ответов напрашивается несколько:
1. Вывод автора статьи правильный - Исполнитель боится за результат и пытается получить все деньги сразу, специально раздувая первый этап. 2. Исполнитель не в состоянии оценить размер проекта, не составив детального описания всех процессов (пусть даже неправильного). Это говорит о слабости Исполнителя. 3. На проектах внедрения работают/руководят слабо-квалифицированные в разработке софта люди (а внедерение ERP - это такой же софт. проект, как и написание склада в Excel - просто более объемный), которые могут отлично знать предметную область, но не имеющие большого и положительного опыта по технологиям ведения софт. проектов.
IgorM: Я набрал запрос "статистика успешных внедрений ERP систем"
Не менее логична и следующая цепочка рассуждений, основанная на этих словах: консультанты зарабатывают больше программистов (факт общеизвестный) - из-за этого сначала платятся бОльшие деньги - на само кодирование, обучение, внедрение остаётся меньше - заранее трудно оценить объем переделок, а их может потребоваться немало - хороших программистов на небольшие суммы не найти (так что получется действительно - неретабельно). Поэтому вывод - либо плохой код в результате, либо вылезаем за бюджет (что тоже не редкость). Слова, про более высокую квалификацию программистов оставим на совести автора (возможно он бывший или настоящий программист :). Квалификация в идеале должна быть высокой у всех.
Справедливости ради отмечу, что у Koder Logic их больше двух выполненных проектов, по крайней мере висит на сайте. А что касается статистики. Я только что взял и набрал на Яндексе запрос "статистика успешных внедрений ERP систем". Из 10 ссылок, две положительные, две нейтральные, остальные говорят о низком проценте "положительных" внедрений. Согласитесь - в рамках страницы результатов поиска Яндекса - это "большинство"
FE: Вы считаете, что обучение и внедрение (то есть опытную эксплуатацию) проводят программисты?
- информация распространяется очень быстро. Поступает она и от заказчика, и от сотрудников исполнителя.
Заказчик рассказывает об этом не на пресс-конференциях, а в кулуарных беседах, и таким способом информация распространяется гораздо быстрее. Просто один финдир скажет своему знакомому другому финдиру, что "вот с этими лучше не работай".
Рассказывают и конкурентам, особенно когда хотят всё-таки что-то сделать. Сливать информацию на тендерах - сливают. Не буду говорить, что это норма, не буду давать моральных оценок, но даже не просто сливают негатив, а откровенно врут.
Так что информация распространяется быстро. В том числе и информация о проектах за 500 000. - Ещё раз об опытной. Этот этап не главный, потому что он очень сильно зависит от предыдущих. Хорошо сделана модель - опытная пройдёт на ура. Плохо сделана модель - есть шанс что-то поправить, но небольшой шанс. Ещё раз повторю: успех или неудача проекта закладываются на предыдущих стадиях, поэтому опытная эксплуатация менее важна, чем они.
| Заметьте, принимается как данность для большинства тех проектов, которые из-за этого закончатся неудачей |
Нет, перечитал статью, всё-таки там автор пытается сказать, что на всех проектах так и не иначе. Так что не могу с Вами согласиться.
- по поводу консультантов. Я несколько не понял Ваши слова: "...на само кодирование, обучение, внедрение остаётся меньше..."
Я понимаю про кодирование, но вот насчёт обучения и внедрения... Простите, Вы считаете, что обучение и внедрение (то есть опытную эксплуатацию) проводят программисты?!?
Далее, если грамотно поставлена задача, то собственно кодирование занимает сравнительно немного времени. Вот постановка задачи - дело гораздо более трудоёмкое. Так что привлечение большего количества квалифицированных консультантов оправдано. Кстати говоря, именно хороший консультант способен правильно оценить объём доработок.
Но вопрос был не в этом, Вы не совсем верно поняли. Противопоставление было не "консультант - программист", а "малограмотный консультант на первых этапах внедрения - квалифицированный на последнем".
- про договоры на каждый этап. Давайте представим себе, что заказчик приходит с такой идеей к исполнителю. Исполнитель совершенно логично будет увеличивать стоимость договора, закладывая туда риски. Надеюсь, не надо объяснять, какие? Значит, заказчику это уже обойдётся дороже, чем договор в целом.
Далее, если исполнитель перестанет нравиться не после первого, а, скажем, после третьего этапа. Заказчик уходит к другому исполнителю, и снова платит за три этапа. Опять риск для заказчика повышается.
Далее, на работу по такой схеме соглашаются тогда, когда проект нужен позарез. Следовательно, крупная фирма с хорошей репутацией пойдёт на такие условия только при особом стечении обстоятельств, а заказчику остаётся выбирать среди мелочи. И снова повышается риск! Как видите, рекомендации статьи приводят не к снижению, а к увеличению риска для заказчика.
| Т.е. Вы утверждаете, что у всех компаний-внедренцев консультанты настолько хороши, что дадут фору любому внешнему, кроме большой четвёрки? |
Нет-нет-нет, ну что Вы! Кто такой "внешний консультант"? Это консалтинговая компания - внедренец. Если она такой же квалификации, то, вероятнее всего, это конкурент. Если квалификация ниже, то как можно доверять им оценку?
- Теперь о количестве проектов Koder Logic. Внедрение Axapta у них заявлено 2 (прописью: ДВА) проекта. Это "Разгуляй" и VDI. Вот ссылка: http://koderlogic.ru/konk.htm
Про "Разгуляй" я слышал отрицательные отзывы, про VDI ничего не могу сказать. Половинкой проекта можно считать сопровождение "Мир детства". Так что я оказался абсолютно прав (хотя и выражался фигурально), что у них два с половиной проекта.
И ещё, IgorM, Вы меня неверно поняли - я не говорю о том, что большинство проектов удачные или неудачные. Я говорю о другом - не надо переносить свой личный опыт (пусть и неудачных проектов) на все остальные. Я полагаю, что анализ причин неудачи проектов - дело серьёзного исследования.
Что касается Вашей ссылки, то в чём-то созвучно статье и точно так же вызывает несогласие.
Garya: Будущая внедренческая компания изначально представлена как рабочая группа, созданная для внедрения на конкретном предприятии
Начать - труднее всего. Видимо, начинать нужно с теми бизнесменами, с кем организатор внедренческой компании знаком лично и они ему доверяют. Либо будущая внедренческая компания изначально представлена как рабочая группа, созданная для внедрения на конкретном предприятии, которое вдальнейшем освоив технологии подобных внедрений, может превратить это умение в бизнес.
Учитывая, что на рынке очень мало добросовестных внедренческих фирм, жестко придерживаясь стратегии "клиент всегда прав" с одной сторны, с другой стороны НЕ берясь за заведомо провальные проекты (по вине клиента такое очень часто случается), можно заработать для себя очень неплохую репутацию и выбиться в лидеры на рынке внедренцев.
Сисой: Вероятность выбрать вороватого внедренца выше, чем квалифицированного. Слишком много Остапов Бендеров на ниве ERP
Да, автор статьи обобщает. И на мой взгляд, правильно делает. По моим оценкам, вероятность выбрать некомпетентного и вороватого внедренца гораздо выше, чем квалифицированного. Слишком высока доходность бизнеса. Слишком много Остапов Бендеров на ниве ERP.
Если внедрений десятки - информация распространяется, это факт. Когда их тысячи, да ведренцев сотни - уже затык. Чтобы информация распространялась, надо, чтобы имя внедренца было на слуху. Что мне даст кулуарная информация о том, что ООО "Атон-68" завалил проект, если директор этой фирмы раз в квартал меняет вывеску, но историю успешных внедрений упорно тащит за собой?
По поводу Опытной эксплуатации: Можно сколько угодно показывать систему проектной группе, ключевым топам, но реальные отзывы от пользователей пойдут только на этапе опытной. А, дьявол, как известно, в мелочах. Я еще ни разу не встречал сопротивления системе на этапе обследования и кастомизации, а вот на этапе опытной эксплуатации - запросто. Вплоть до увольнения инициаторов проекта и разрыва отношений с Исполнителем. И речь даже не о психологии менеджеров Заказчика. Именно на этом этапе "мухлевать" становится практически невозможно. Вот она - неработающая система.
LSV: Невозможно привлечь опытных специалистов, они заняты на более важном проекте
|
FE Таким образом, следуя логике автора, при использовании квалифицированных специалистов весь проект не может быть рентабельным. Это противоречит действительности. |
Не противоречит ! Даже самая безграмотная контора хочет иметь ВСЕ ПРОЕКТЫ УСПЕШНЫМИ. Искренне хочет ! Но что этому мешает ? Ответ банальный: невозможность привлечь опытных специалистов. Их либо нет, либо они заняты на более важном проекте. Привлечение их завышает временнЫе и финансовые рамки проекта, которые обычно и так узкие донельзя. Безболезненно расширить эти рамки удаётся не всегда.
Пока спрос на автоматизацию в РАЗЫ больше, чем имеется грамотных исполнителей, до тех пор будут Бендеры и Насреддины (или ишак сдохнет, или шах или я).
Расчёт что "про провал никто не узнает" тоже верный. Не так уж часто это становится достоянием гласности. Те, кто в состоянии оценить успешность проекта могут побояться сообщить общественности про провал. Обычно инфа передаётся из уст в уста. О какой гласности и объективности тут речь ?
Заказчики ещё очень разрозненны и мало знают данную область ИТ, чем успешно пользуются горе-внедренцы.
ЗЫ: В целом статья верная.
Привалов: ERP - это не стандарт - это методология, подход к организации производства
Полностью поддерживаю FE. Более того, выражаю тебе (FE, чтобы никто не перепутал) свое глубокое уважение. Очень (!) подробно, и главное. последовательно приведены аргументы, мысль изложена четко и грамотно, доступно для каждого (кто в состоянии прочитать перед тем как постить свое частное видение).
Статья не просто идиотская, она вредная. Ибо она формирует и узаконивает дилетанство в очень важных вопросах, что не допустимо. В целом, журнал Компьтерра деградировал столь сильно, что лишний раз об этом говорить уже бессмыслено. Так что эта статья вполне в духе.
Но в сторону лирику. По существу. Спор возник ввиду того, что автор употребил термин ERP в заголовке, а речь шла об построении небольшой локалки в бухгалтерии (это сарказм, не стоит цепляться к словам). ERP - это даже не стандарт - это методология, подход к организации производства. Компания автора статьи (Koder Logic) этим даже не занимается. То что они делают с аксаптой - понятия не имею. Но потребность в ERP идет сверху, от руководства фирмы, готового сделать стратегическую инвестицию. Навязать ее невозможно. Если кто то считает, что здравомыслящий человек, руководитель, владелец предприятия способен потратить год работы и кучу денег, не предполагаю результат - то это не правда. Идля этой рабоы привлекаются крупные фирмы с мировой репутацией и внедрение - это их совместная работа, никто ни кого не парит. Успешный проект - тот, который действительно позволил заказчику снизить издержки, сформировать отчетность по мировым стандартам, выстроить систему и тд.
То что описано в статье - вообще из другой оперы, и отношения к проектам ERP не имеет Так чтообсуждение статьи не может лежать в области здравого смысла, так как описываемы в статье процесс не существует
Сисой: 180 тысяч USD за два первых этапа, никто ничего внедрять не собирался. Как предприятие подписало договор?
|
Привалов В целом, журнал Компьтерра деградировал столь сильно, что лишний раз об этом говорить уже бессмыслено. Так что эта статья вполне в духе..... То что описано в статье - вообще из другой оперы, и отношения к проектам ERP не имеет Так чтообсуждение статьи не может лежать в области здравого смысла, так как описываемы в статье процесс не существует |
Ого... Значит, параллельные миры все же существуют. Иначе противоречия между участниками форума сложно объяснить.
Уважаемый господин Привалов! Я лично участвовал в подобном проекте в качестве РП (когда понял, в чем дело - уволился). Это было в 2002 г. Из Заказчика было вытянуто 180 тыс. USD за два первых этапа, реально никто ничего внедрять не собирался. Объяснить, как предприятие подписало договор? Очень просто - финдир управляющей компании получил "откат" и заставил под угрозой увольнения подписать договор директора дочерней компании. А Вы о снижении издержек.... И такое "внедрение" не единственное.
Привалов: Какой ERP-проект можно считать успешным? Кажется, речь пойдет о ERP и методологии внедрения систем, однако, эта тема не раскрыта
2 Сисой. Существует еще много чего.
Дело в том, что суть описываемых в статье процессов к ERP отношения не имеет. Так как и приведенное тобой уголовное преступление. Этот печальный факт так же далек от вопросов систем управления производством, как и статья.
Первое же предложение в статье: Какой ERP-проект можно считать успешным?
И следует ожидать, что и речь пойдет о ERP и методологии внедрения систем. Однако, эта тема не раскрыта, а статья переполнена описанием частного подхода к разворачиванию некоторой информационной системы.
Предлагаю оспорить этот факт, и тогда можно будет перейти к деталям, цитировать статью и оценивать насколько этот частный опыт пригоден к применению - что и происходит в форуме.
