Что-то у меня возникают сомнения по поводу качества этой статьи, хотя я и не читал её... Люди, которые не умеют писать нрамотно даже у себя на сайте, вряд ли могут сказать что-либо умное...

Тогда хотелось бы почитать...

Мда... Всё-таки я был прав - человек, не умеющий грамотно писать, вряд ли сможет сказать что-то умное. Или намеренно не говорит...

"В начале обследование, потом настройка системы и наконец внедрение. ... Последний и главный этап - собственно внедрение" - Внедрением называется весь процесс. Обследование и настройка точно так же входят во внедрение. Непонятно, что именно в таком контексте автор называет внедрением. Обучение пользователей? Ввод данных? Опытную эксплуатацию? По крайней мере, ясно, что это не обследование и не настройка.

"Это самая сложная часть, в которой и заключается суть проекта." - это не самая сложная часть.

"Если внедрение прошло удачно - даже при отсутствии предыдущих этапов (что, в принципе, возможно - есть примеры), то и весь проект будет успешным." - фигня. Точно так же я могу написать - "если опытная эксплуатация прошла удачно..." и далее по тексту.

"Поэтому все этапы до внедрения называют предпроектными работами." - простите, у кого они так называются? У Koder Logic? Так это не показатель.

"Все начинается с того, что руководство Заказчика принимает решение о начале проекта. В этот момент Исполнитель обычно еще не известен, и курировать проект начинает собственный специалист Заказчика. Его так и называют - Куратором проекта. " - боже ж мой... Могу только порадоваться за тех, кто работает с заказчиками, у которых до выбора системы есть куратор проекта! Обычно всё начинается со смутного беспокойства некоторых людей заказчика, которое потом уже может вылиться в попытку что-то выбрать.

"Он отвечает за формирование команды, которая подготовит проект, распланирует его и выберет исполнителя. " - нет в большинстве случаев такой команды! Нет ни плана проекта, ни подготовки. То, что описано в статье - идеальные, тепличные условия, о которых можно только мечтать!

"Введем упрощение. Будем считать, что невнедренный проект не влияет на репутацию Исполнителя. Это не совсем верно, но верно настолько, что мы можем это допустить" - ну, у кого репутации нет, для тех это верно. Для остальных это допущение в корне неправильно.

"Исполнитель знает, что составить такие описания бизнес-процессов и другую требуемую для проекта документацию, которую подпишет комиссия Заказчика, в общем-то нетрудно." - с чего это? Нет, конечно, если в "комиссию" набрать уборщиц, то, наверное, так и есть. Только вот нам на проектах всё больше попадаются въедливые и дотошные заказчики, у которых просто так ничего не подпишешь, и которые очень хорошо умеют считать деньги и хотят получить за них результат.

"Компетентные специалисты Заказчика не любят сбои в работе процесса, так как несут за них реальную ответственность. Если в описании БП такой сбой не будет описан, это произведет благоприятное впечатление на подсознательном уровне." - просто полный бред! Фрейд домашнего розлива...

"Техническое задание - это задание Заказчика Исполнителю. Не странно ли, что и его готовит Исполнитель? " - очень странно. Именно поэтому заказчик не оставляет этот процесс на самотёк. Конечно, в реальных проектах, а не в высосанных из пальца примерах.

Кстати, автор статьи Дмитрий Мартынов несколько лукавит - не доказав, что начальные документы не соответствуют потребностям проекта, в дальнейшем он принимает это как постулат. Кроме того, когда один документ готовится на основании другого, вовсе не факт, что ошибки первого перенесутся во второй документ, они, наоборот, могут быть исправлены.

"2.5. Обучение (свет в конце тоннеля)

Этап может принести большую пользу Заказчику в смысле контроля за подготовкой проекта." - простите, контроля за чем? За подготовкой проекта ? Какая, в задницу, подготовка - проект идёт полным ходом!!!

"у Заказчика должна быть грамотная проектная команда, мотивированная на результаты проекта." - чуть ли не первая справедливая мысль. Впрочем, она настолько тривиальна, что даже стыдно такое читать.

"Когда будет выполнено все, кроме последнего этапа, нет гарантий, что полученная система сможет быть внедрена." - открою страшную тайну Дмитрию Мартынову - такой гарантии нет даже после того, как подписан акт и система должна начать работать. Гарантий нет вообще! И нет их не потому, что злобный и коварный исполнитель дурит наивного и простоватого заказчика, а потому, что на работоспособность системы влияет слишком много сторонних факторов.

"Для получения небольшой части оставшихся денег Исполнителю надо затратить солидные ресурсы и подключить квалифицированных специалистов, то есть внедрение для Исполнителя нерентабельно." - если так рассуждать, то вообще внедрением заниматься не надо. Вообще-то приличные фирмы подключают квалифицированных специалистов с начала проекта, и команда делает весь проект, в том числе и тот этап, который Дмитрий Мартынов загадочно называет "внедрением". Так что солидные ресурсы тратятся всегда, то есть, по логике Мартынова, нерентабельно всё внедрение в целом.

"Невыполнение обязательств по договору - тоже риск несущественный. Договор готовил Исполнитель и заранее продумал наличие в договоре лазеек для сложившейся ситуации." - вот так вот просто взял и отмёл этот риск! Несущественный, понимаете ли! Не надо считать заказчика неразумным ребёнком, он вполне понимает, за что платит деньги и что хочет получить в результате.

"Последний этап обычно очень сложен. Прежде всего из-за низкого качества выполнения задач предпроекта. " - это да, это правда. Если остальные этапы низкого качества, то загадочное "внедрение" Дмитрия Мартынова тоже будет низкого качества.

"Менеджеры нижнего звена порой не подозревают, что многое изменится, тогда как внедрение зачастую в корне меняет процессы управления. Это производит колоссальный эффект. Именно тогда представления о том, как и что должна уметь система, радикально меняются и доходят до руководства Заказчика. " - переведите кто-нибудь эту фразу!!! То есть менеджеры низшего звена ничего не подозревают, потом резко меняются процессы управления, и потом это всё доходит до высшего руководства?!? Блин, это ж надо такую чушь написать!

"В результате в сообществе ERP звание "программист" менее престижно, чем звание "консультант", несмотря на то что первая профессия изначально подразумевает более высокую квалификацию." - вообще-то это неправда. С какой стати программист подразумевает более высокую квалификацию?

Да, кстати. Чуть выше в статье автор говорит, что "Риск потери репутации отсутствует - мы ввели такое допущение (почему, объясняется в разделе "Итоги не для всех"). " Так вот, нет в этом разделе никаких объяснений.

"Один из вариантов повлиять на качество предпроектных работ (описание бизнес-процессов, техническое задание) - это заключать на них отдельные договора с Исполнителем." - да?!? Правда?!? Это снижает риск?!? Если следовать предыдущим рассуждениям автора, то исполнитель кое-как малыми силами делает описание, быстренько его сдаёт, получает деньги и ищет следующий проект. Маржа будет достаточно высокой, ответственности никакой, а заказчик остаётся с ненужным ему описанием бизнес-процессов и идёт искать следующего исполнителя, чтобы снова заплатить ему за то же самое. Офигенное снижение риска! :D

Прощу прощения за столь обильное цитирование, но, честное слово, эта статья не может оставаться без отклика. Такими "статьями" они просто сами себе копают яму, и да чёрт бы с ними, но ведь люди могут подумать, что и другие фирмы так делают!

И они ещё говорят, что они внедряют Axapta! Сделали два с половиной проекта, и теперь начинают учить других...

Сисой , не могу с Вами согласиться.

Вот как раз я не переношу свой опыт на все внедрения, поэтому и не говорю, что "бывает так, и не иначе", в отличие от безаппеляционной манеры автора статьи.

Большинство менеджеров считает "внедрением" что-то вроде опытной эксплуатации, а Обследование, Настройка - это вне их восприятия.

Тоже не согласен. По моему опыту, это совсем не так. Более того, я лично ни разу не сталкивался с менеджером, который бы под "внедрением" понимал что-то вроде опытной эксплуатации. Конечно, вводить классификацию - право автора, но:
1. Желательно, чтобы она соответствовала общепринятой;
2. В случае отклонения желательно иметь обоснование отклонения и определения.

Автор изменяет устоявшиеся термины и не даёт никакх пояснений.

А вот подмена понятий недопустима! Упрощение - да, но до тех пор, пока оно не приводит к неверным результатам. Выводы же автора неверны в корне.

Я неоднократно встречался на реальных проектах со всем тем, что пишет автор статьи. В том числе и с Кураторами, выбирающими системы. Вот, к примеру, текущий проект - именно такой.

Охотно верю. Только отвечу Вам Вашими же словами: "не надо переносить свой субъективный опыт на все внедрения". Надеюсь, Вы не будете утверждать, что всегда и везде до выбора системы создаётся будущая группа проекта во главе с куратором?

iscrafm, Вы привели выдержку из словаря? Так она в данном случае бесполезна, потому что существуют устоявшиеся в отрасли термины. Внедрением называется весь проект, от начала обследования до сдачи в промышленную эксплуатацию. Так что то, что автор называет "внедрением" - это отнюдь не самая тяжёлая часть.

Нет, не спорю, для каких-то фирм, возможно, это и правда, всё зависит от методологии внедрения. Только вот я бы на месте заказчика не связывался с фирмами, у которых такая методология.

И ещё почему я так резко реагирую на статью - если бы Дмитрий Мартынов написал "мы делаем вот так, и у нас возникают такие проблемы", то я бы просто посмеялся над статьёй и занёс в архив курьёзов. Однако он начинает строить обобщения, вот в чём беда!

Согласен с gag - статья полностью непрофессиональная.

iscrafm, я говорю об отрасли внедрения информационных систем класса ERP. Там обследование является частью внедрения, это есть и у SAP, и у Oracle, и у Axapta.

В какой отрасли Вы работаете, я не знаю.

iscrafmЯ бы тоже не советовал связываться с конторами, которые внедрением считают решение собственных проблем.

Полностью согласен.

iscrafmМетодология, о которой Вы упоминаете, позволяет раскрутить заказчика на большую сумму с меньшими потерями для себя, а речь идет о том, чтобы система заработала.

Я не упоминаю ни о какой конкретной методологии. Впрочем, предположим, что имеется ввиду что-то конкретное.

- Правильно ли я понимаю, что Вы согласны целиком или по большей части с обсуждаемой статьёй?

- Правильно ли я понимаю, что Вы готовы защищать статью?

- Правильно ли я понимаю, что Вы обвиняете все компании, которые занимаются внедрением и не придерживаются точки зрения автора статьи, в выкачивании денег?

Статью про "чёрные" проекты читал ещё раньше, спасибо, что напомнили. Но та статья коренным образом отличается от этой, а именно тем, что в статье на cnews основной тон - "бывает", а не "только так, и не иначе". Кроме того, статья cnews говорит немного о другом, если Вы не заметили.

С той статьёй с некоторыми оговорками я могу согласиться - да, так бывает. Совет только один - не связывайтесь с такими ИТ-компаниями.

iscrafm, не смотрел Ваш профиль.

iscrafmАвтор считает, что внедрение - это установка уже адаптированного к предприятию продукта и его опытная эксплуатация.
Во-первых, нигде в статье данного определения нет. Во-вторых, дело не в игре словами, а в общепринятых терминах. Если хотите менять их - пожалуйста, только желательно дать определение и обосновать необходимость изменения понятий.

На самом деле, это уже вторично, я готов принять Ваше определение внедрения (жаль, правда, что Мартынов ничего не написал по этому поводу).

iscrafmНет. Я говорю только о том, что много проектов умирают именно на стадии внедрения в понимании автора. Зато с рапортом о завершении внедрения :)
Это хорошо, что Вы не бросаетесь обвинениями, приятно слышать разумного человека. Не могу не согласиться с Вашим высказыванием. Правда, могу добавить, что много проектов умирают и после "внедрения" в понимании Мартынова, и тоже с рапортами.

Теперь по статье. iscrafm, Вы согласны с допущением, что компании-внедренцы не заботятся о своей репутации? Заметьте, не некоторые, а все.

Второй вопрос - как Вы полагаете, iscrafm, насколько трудоёмко "внедрение" Мартынова, если предыдущие этапы выполнены качественно?

Третий вопрос - как Вы можете объяснить пассаж по поводу "невыгодности внедрения", а именно то, что необходимо привлекать квалифицированных специалистов? Согласны ли Вы в этом с Мартныновым, или же полагаете, что квалифицированных специалистов необходимо привлекать с самого начала проекта?

Вот видите, iscrafm, Вы тоже согласны, что компании заботятся о своей репутации. Вся же статья написана в том предположении, что этого нет.

"Это не совсем верно, но верно настолько, что мы можем это допустить ...."

С ситуацией, когда исполнитель сам контролирует проект, лично не сталкивался. Видимо, нам попадаются более строгие и придирчивые заказчики. Поэтому делать допущение такое и строить на нём всю статью категорически нельзя.

iscrafmМы, например, бывает запускаем систему в режиме "горячей замены" и сталкиваемся с такими особенностями, которые не пропишешь в ТЗ, как не старайся. Просто их не видно, пока некоторое время пользователи не поработают и не повылезают разные "тараканы".
Согласен. Только ведь это именно особенности , а не кардинальная перестройка всех процессов по-новому, верно? Таким образом, получается, что грамотное описание бизнес-процессов и грамотное проектирование системы - залог успешной эксплуатации, как опытной, так и промышленной.

iscrafmНа проект в принципе нужно привлекать квалифицированных специалистов. Считаю, что вопрос на каком этапе - просто неуместен.

О! Вот видите! Если же следовать логике статьи, то в этом случае всё внедрение (я имею ввиду полное) - бессмысленно и нерентабельно. Как же Вы работаете, хочется спросить?

iscrafm, в том-то и дело, что перечисленных граблей легко избежать, и наступать на них могут только те, кто совсем не умеет работать! Кроме того, перечисленные грабли возникают при совершенно невероятном стечении обстоятельств. Утверждать (как это делается в статье), что такие случаи типичны, я бы не рискнул. А уж рекомендации, которые даёт автор, настолько тривиальны, что просто стыдно их читать.

авторСтараемся заработать прибыль и репутацию. Одновременно. А Вы разве не так? :)
Вот именно, что стараемся заработать прибыль и репутацию одновременно. А вот статья взаимоисключает эти два понятия.

Сисой, есть термины, которые понимаются большинством компаний одинаково. Нет юридического документа, закрепляющего эти понятия, но есть практика работы. Так вот, Вы не хуже меня знаете, что и ASAP, и ON TARGET понимают под внедрением. Более того, если Вы будете общаться с представителем мало-мальски крупной компании (IBS, TopsBI, SAP, BDO, Корус, Columbus, GMCS, АНД, et cetera...), то под "внедрением" будет пониматься процесс в целом, а не этапы обучения пользователей и опытной эксплуатации.

Спорить по этому поводу я не вижу смысла, потому что здесь переубедить меня вря дли удастся. Как я уже говорил выше, если автор хочет дать своё определение - ради бога, только нужно само определение и обоснование. Предлагаю вернуться к обсуждению статьи, а не "придираться к словам", как Вы справедливо заметили.

iscrafm, моё замечание о неумении работать относилось в основном к исполнителям, а не к заказчикам. Впрочем, Вы ведь согласны с тем, что заказчики разные, и не стремитесь обобщить положения статьи на всех. Именно об этом я и говорю - не стоит личный опыт обобщать на всех, да ещё опыт, свидетельствующий о странных (мягко говоря) подходах к внедрению.

Да, я работаю в компании-внедренце. Только вот Koder Logic для нас не конкуренты, они слишком маленькие.

Про неудачные внедрения не спорю, их есть, только проблемы там возникают совсем не так, как описано в статье. И совет только один - не связывайтесь с компаниями, которые внедряют описанным в статье способом. Скажу более - нормальные компании так не внедряют.

IgorMИ как же они внедряют? И самое главное, где их взять-то эти компании? Я так понимаю, на мелочи они не размениваются?
Внедряют - по другому. Качественно.

Где взять? Ищите. Слушайте, что Вам говорят, оценивайте, думайте.

Насчёт мелочей - смотря что считать мелочью.

IgorMОсобенно интересно бывает смотреть, когда пытаются "парить", не зная, что ты тоже ориентируешься в вопросе.
И кто же Вас пытается парить, а? Откройте секрет, прошу Вас!

СисойДа, он по ту сторону баррикад. А мы - по эту.
Сисой, мне жаль, что у Вас такой подход. Я никогда не воспринимал заказчика как противника, я всегда стараюсь воспринимать его как партнёра. Скажите, когда Вы внедряли (если я не ошибаюсь), Вы (как в статье сказано) стремились по-быстрому сорвать деньги, плевали на репутацию, подсовывали заказчику стажёров, делили проекты на референсные и второстепенные? На Ваш взгляд, к примеру, Сергей Мазуркин так поступает?

Впрочем, мы сейчас обсуждаем не внедренческие фирмы в целом, а конкретную статью. Так вот, на мой взгляд, статья глупая, потому что основана на неверных предпосылках - раз, переносит частный опыт автора на все внедрения - два, и заканчивается или тривиальными, или неверными рекомендациями - три.

СисойК уважаемому mazzy это не относится, но я знаю не одну и даже не две компании, внедряющие продукты MBS таким образом.
Сисой, согласен. Получается, что есть компании (как минимум одна), которые внедряют нормально? Получается, что описанные в статье проблемы не общие для всех внедрений? Вопросы риторические, на самом деле...

СисойС точки зрения Заказчика бороться с таким подходом можно, в частности, путем выделения отраслевых центров компетенции по внедрению.
Тоже согласен. Значит, заказчику остаётся выбор - или идти в один из отраслевых центрв, или обращаться в маленькую фирму с двумя проектами на свой страх и риск. На мой взгляд, проблемы, описанные в статье, характерны именно для маленьких фирм.

IgorM, могу вкратце повторить свои тезисы:
- неверно допущение, что внедренцы не заботятся о своей репутации;
- неверен взгляд, что главным обязательно является этап опытной эксплуатации ("Внедрение" в терминологии Мартынова);
- неверно допущение, что заказчик смотрит сквозь пальцы на качество предоставляемых ему документов;
- неверно допущение, что квалифицированные консультанты должныпривлекаться только на последнем этапе;
- неверно обобщение опыта автора на все проекты внедрения (а статья говорит именно об этом, о том, как избежать "рисков" для всех проектов. На ряде проектов описанные "риски" просто не возникают);
- неверно предположение о том, что "плохие" документы первых этапов не могут быть исправлены в последующем;
- рекомендации статьи 3.1 и 3.2 неверны, а 3.3 - 3.6 тривиальны. Ради этого не стоило писать статью.

Мои слова о том, что надо слушать, оценивать и думать, относились к поиску компаний, а не к методологии внедрения. К сожалению, по моему мнению, невозможно дать полезные общие рекомендации, как сделать успешным тот или иной проект. Всё сведётся опять к тривиальным советам вроде "сформируйте заинтересованную группу внедрения со стороны заказчика" или "делайте работу хорошо".

Для заказчика при выборе компании-внедренца, наверное, полезным будет просить у компаний обосновать свой подход, свой план внедрения. Тогда заказчик сможет оценить, насколько хороши аргументы той или иной компании, сравнить их со своим в и дением процесса, может быть, изменить своё мнение. Желательно, чтобы заказчик не просто выслушивал аргументы, а был открытым для общения, потому что читать мысли пока ещё затруднительно ;-) Повторюсь, это рекомендации тривиальные.

ВалентинК, для краткости я говорю "внедрение", хотя можно говорить и "проект внедрения". В документах чаще использую "проект внедрения".

IgorM,

- информация о неудачном внедрении распространяется достаточно быстро. Пусть официально об этом не объявляют, но заказчик об этом рассказывает. Имел возможность убедиться неоднократно. Кроме того, рынок не так уж и велик, все друг друга знают. Разумеется, информация о неудачном внедрении в холдинге "Объединённые ларьки у метро Алтуфьево" долго не будет известна, но мы же говори о более-менее крупных проектах?

- этап опытной эксплуатации является не главным, потому что успех или неудача проекта закладываются на более ранних этапах. Проект может быть неудачным даже после официального завершения опытной. Примеры, к сожалению, не имею права приводить, но их есть у меня.

- Оценка заказчиком качества документов - смотрим разделы статьи 2.1, 2.2 (второй абзац). В дальнейшем то, что документы не соответствуют потребностям проекта, принимается как данность (раздел 2.3, второй абзац, раздел 2.7, первый абзац). Это неверно потому, что
а) Далеко не каждый заказчик невнимательно читает документы;
б) "плохой" документ на первом этапе может быть исправлен на последующих.

В статье подобные проблемы приводятся как типичные и характерные, хотя мой личный опыт говорит об обратном.

- Привлечение квалифицированных специалистов. Раздел 2.6, предпоследний абзац, цитирую: "Для получения небольшой части оставшихся денег Исполнителю надо затратить солидные ресурсы и подключить квалифицированных специалистов, то есть внедрение для Исполнителя нерентабельно."

Из этого я делаю вывод, что, раз квалифицированных специалистов надо подключать на этом этапе, то ранее они не подключались. Кроме того, это подтверждается словами автора "... то есть внедрение [при использовании квалифицированных специалистов] для Исполнителя нерентабельно". Таким образом, следуя логике автора, при использовании квалифицированных специалистов весь проект не может быть рентабельным. Это противоречит действительности.

- риски, Вы совершенно правы, действительно не возникают потому, что их обходят. Достаточно всего лишь заказчику быть внимательным к документам, а исполнителю хорошо готовить эти документы и хорошо работать с самого начала, и тогда этап опытной эксплуатации проходит как по маслу, и все довольны! ;-)

- почему не нужен отдельный договор на каждый этап (а не на описание БП), я уже писал.

- внешние консультанты... Вы знете, если это будут аудиторы из большой четвёрки, я, пожалуй, признаю их полезность. Только для заказчика это будет очень дорого стоить. ;-)

- Раздел 3.2... Вы знаете, эта рекомендация не приведёт ни к каким последствиям. Просто, если дело дойдёт до суда (крайний случай), заказчик честно может заявить - "да, качество отвечает потребностям". И что заказчик будет делать дальше в суде? Опять говорить "А мы имели ввиду вот это"?

Обезопасить себя от некачественного проектирования таким способом невозможно, поэтому рекомендация глупая.

- а как надо Вы не говорите, потому как всё тривиально
Именно поэтому я и не пишу статьи, потому что мой личный опыт не позволяет сделать обобщения, я прекрасно понимаю, что все ситуации в проектах мне не охватить.

Упреждая вопрос - опыт не позволяет обобщить, но вот опровергнуть обобщение - для этого достаточно иметь опыт хотя бы по одному проекту.

Я полагаю, что подобные статьи можно писать на основании серьёзных исследований, в том числе и статистических, но никак не на основании двух сделанных проектов.

- уверенности в том, что заказчик сможет правильно выбрать компанию, у меня нет. Гарантии здесь дать невозможно, можно только оперировать вероятностью.