От s_ustinov:
 

lessonslearned

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

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

lessonslearned

s_ustinov

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

Согласен, что не простой вопрос. На старте для выявления требований выделено 4 недели. Провала нет. :)

я не уверен, что это можно отнести к требованиям.
в том то и дело, что это РАЗРАБОТКА структуры справочников...
я понял, что меня смущает в вашем подходе - больше внимания уделяется функционалу программ, а не внедрению как таковому. а это не правильно.

lessonslearned

s_ustinov

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

Но ведь как-то же люди в с/х работают? Думаю, что и планирование осуществляют в том числе…

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

кстати, это очень хороший пример того, как можно сильно ошибиться на самом раннем этапе с объемом работ
и если реализовывать так, как ты описал - вылезет все уже в самом конце
описываешь заказчику, вот мол так и так - он, не разбираясь глубоко в предмете, кивает - ага, ага (подразумевая, что звучит красиво и вроде примерно такое ему и надо)
и вот все сделано, разработчики протестировали функционал, начали показывать все заказчику - пробуют составить приблизительный план
говорят - а вот здесь укажите, сколько вы денег на солярку потратите по месяцам...
а фермер в непонятке - а откуда я знаю - там все от погоды зависит (когда посевная, когда уборочная), да и цены меняются... ну хоть примерно - ну тонны 5 на посевную...
а в деньгах?...
в результате заказчик понимает, что система не может ни диапазоны нормально обрабатывать (от 3 до 4 тонн), ни автоматически пересчитывать суммы, когда ей указываешь изменение цен, ни нормально сроки сдвигать - посевная, уборочная и т.п. - сильно зависят от погоды, и сдвигаются плюс-минус неделя-две (соответственно, и все платежи сдвигаются)
в результате заказчик заявляет - че вы мне фигню пытаетесь подсунуть? такое, что вы мне предлагаете, я и сам в екселе могу, а ексель у меня уже на компе стоит.. и не буду я вам за все это платить - мы как договаривались - что вы сделаете что-то, что поможет мне реально планировать ДДС, а эта фигня мне в этом не помогает - следовательно, денег вы не получите.

я примерно про такие ситуации и говорил, что на мелких проектах ошибки бывают ОЧЕНЬ значительные

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

От lessonslearned:
 

s_ustinov

я не уверен, что это можно отнести к требованиям.
в том то и дело, что это РАЗРАБОТКА структуры справочников...
я понял, что меня смущает в вашем подходе - больше внимания уделяется функционалу программ, а не внедрению как таковому. а это не правильно.

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

s_ustinov

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

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

s_ustinov

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

Опять же не вижу связи между водходами к внедрению и планированием ДДС. Хорошо, пусть не сработает. Напишите, какой подход у фермеров к планированию ДДС сработает и, думаю мы увидем, что противоречия с методикой внедрения данного подхода к планированию ДДС не будет :)

s_ustinov

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

Что-то в этом есть. У меня подразумевалось что, собственно, упор делается на грамотном ТЗ, т.е. если оно составлено неверно, то получится уныло... На самом деле в предложенном подходе подобные ошибки всплывут на стадии составления тестовых сценариев, когда нужно будет писать ожидаемый результат (Этап проектирования), что отнюдь не в самом конце.

s_ustinov

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

я примерно про такие ситуации и говорил, что на мелких проектах ошибки бывают ОЧЕНЬ значительные

Опять же углубились в ситуацию с планированием ДДС, что на мой взгляд нисколько не зависит от выбора итерационного или водопадного подхода и нисколько не противоречит предложенной методики внедрения

s_ustinov

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

И как этого избежать (ошибок с оценкой трудоемкости и нехватки опыта)?

От lessonslearned:
Андрей Ж.,

Прочитал. Не все понял. Например, что подразумевается под Ж. "Настройка техники на оптимальную работу с пакетом. "?

От Андрей_Ж:
 

Прочитал. Не все понял. Например, что подразумевается под Ж. "Настройка техники на оптимальную работу с пакетом. "?

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

Конкретно в данной фирме - локальная сеть входит в домен Московской конторы, требования которой звучали:

1. Полный доступ к информации программы, в том числе средствами "предыдущей" системы.
2. Запрет использования технических средств их "глобальной" сети.
3. Совместное использование их и "моих", взаимоконфликтующих средст безопасности.

От s_ustinov:
 

seider

lessonslearned, я конечно понимаю что сложно реализовать систему для микро предприятия, но я считаю, что нужно ёё сначала спроектировать в каком либо Case-средстве(программе) наподобие Rational Rose 2000 Enterprize Edition и/или Erwin, а потом непосредственно приступать к созданию
отчётных документов и программированию.

Речь идет не о создании, а о внедрении уже СУЩЕСТВУЮЩЕЙ системы. То есть доработки возможны, но не обязательны и даже не очень желательны.

От s_ustinov:
 

Андрей Ж.

В качестве условия нужно было предоставить календарный и финансовый план, а так же определить сроки внедрения в письменном виде.
Календарный план внедрения:

Август.

При успешном вводе остатков возможен переход на новую систему, при условии параллельного ведения двух программ. Принятие решения о смене ПО.

Сентябрь.

Проведение ревизии склада (инвентаризация) – четкое определение остатков, выставление долгов по поставщикам, покупателям и прочим клиентам.

Я правильно понимаю, что частично работа начинается в первый же месяц, а полноценная работа через 2 месяца?

От s_ustinov:
 

lessonslearned

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

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

lessonslearned

s_ustinov

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

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

объем внедряемого функционала
когда внедряется "все и сразу", намного легче пропустить косяк такого рода
с утверждением "не заработает при обоих подходах" я согласен

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

lessonslearned

Напишите, какой подход у фермеров к планированию ДДС сработает и, думаю мы увидем, что противоречия с методикой внедрения данного подхода к планированию ДДС не будет :)

в рамках ограничений примера проекта внедрения (сроки, бюджет) данную задачу (планирование ДДС) решить скорее всего нельзя

lessonslearned

У меня подразумевалось что, собственно, упор делается на грамотном ТЗ, т.е. если оно составлено неверно, то получится уныло... На самом деле в предложенном подходе подобные ошибки всплывут на стадии составления тестовых сценариев, когда нужно будет писать ожидаемый результат (Этап проектирования), что отнюдь не в самом конце.

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

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

lessonslearned

Опять же углубились в ситуацию с планированием ДДС, что на мой взгляд нисколько не зависит от выбора итерационного или водопадного подхода и нисколько не противоречит предложенной методики внедрения

s_ustinov

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

И как этого избежать (ошибок с оценкой трудоемкости и нехватки опыта)?

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

От s_ustinov:
Проблемы водопада
главные проблемы - нет механизма управления сложностью проекта и НЕРЕАЛЬНО высокие требования к качеству ТЗ.
внедрения сайта - относительно простая задача. внедрение бухучета - уже задача значительно сложнее. а внедрение бухучета, продаж и закупок, склада, производства, планирования денег и продаж и изощренного ценообразование с кучей скидок - это уже ОЧЕНЬ сложная задача. на практике, когда я слышал о внедрении большого количества модулей, ВСЕГДА проект был или неудачный, или со срывом сроков и превышением бюджета (речь идет и о больших и о малых предприятиях). возможно, я не о всём слышал, и есть где то примеры успешных внедрений, когда успешно сразу внедрялось всё... буду рад услышать ссылку на такой пример.

У итеративного внедрения 2 основных недостатка:
1. более высокая стоимость - если все идеально, то при итеративном внедрении мы сначала настраиваем модуль для работы отдельно от остальных, а потом перенастраиваем для совместной работы с другими модулями. соответственно больше трудозатраты на настройку, обучение и переобучение пользователей, инструкции пользователей и т.п.
но обычно не все идеально, и итеративный подход оказывается дешевле
2. больше времени. то, что при водопаде можно распараллелить (больше людей привлечь на проект), при итеративной методике может быть сделано только последовательно. опять же, водопадом более быстро получается только для идеального случая :-)))

Но несмотря на эти недостатки, итеративный метод дает более предсказуемый результат и меньше проблем при такой методике.

очень хорошо о проблемах водопада и сложности системы, а также почему итеративный вариант лучше, сказано у Брукса, хотя там идет речь о разработке, но и к внедрению все применимо. смысла повторять я не вижу - лучше почитать оригинал (особенно последние главы МЧМ).

также при итеративной методике на обучение пользователей отводится на ПОРЯДОК больше времени, и обучаются они по более "правильному" с точки зрения психологии способу - сперва относительно простые вещи, которые делаешь постоянно, потом более редкие и сложные, которые требуют более глубокого понимания работы системы. а в водопаде учат сразу всему, и у пользователей чаще происходит отторжение системы.

От s_ustinov:
 
кусок, еще не все дописал, но уже можно смотреть

Методология внедрения
Этапы проекта.
Диагностика

* Определение списка требований к системе, которые необходимо (желательно) выполнить в данном проекте. Список состоит из достаточно крупных блоков. В требования включаются только прикладные задачи, технические аспекты обсуждаются отдельно. Кроме прямо упоминающихся клиентом надо обязательно уточнить, какая функциональность имеющейся системы или систем используется. Все требования делятся на несколько групп:

1. Обязательный (критический) функционал, необходимый для выполнения обычных, повседневных операций (если используется некая система, он там обязательно есть). Пример - регистрация получения наличных денег, регистрация продажи товара и т.п.
2. Прочий обязательный функционал, который используется время от времени. Пример - формирование (получение) данных для расчета налогов.
3. Функционал, без которого можно обойтись, но выполнение некоторых операций будет очень неудобным и трудоемким. Пример - при возврате система сама автоматически проставляет ссылки на подходящие документы продажи, вместо того, чтобы пользователь вручную указывал нужные ссылки для каждой позиции в документе (при большом количестве возвратов существенно сказывается на производительности).
4. Функционал, который позволяет предприятию улучшить работу и/или добиться конкурентных преимуществ (обычно именно то, ради чего выполняется внедрение новой системы). Пример - учет товаров на складе в разрезе ячеек, расчет зарплаты сотрудников в зависимости от ряда показателей, поддержание оптимального уровня запасов на складах филиалов в автоматическом режиме и т.п.

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

* Составляется таблица наличия возможностей по внедрению каждого из требований. Существует 4 области оценки:
1. Знания и навыки клиента в данной области: -1 - не выполняют такие функции (нет опыта); 0 - выполняют, но результатом выполнения недовольны (возможно, неправильный подход или алгоритм - есть знание, как не получится (неправильно) делать); 1 - выполняют такие функции и результат удовлетворительный (есть необходимый опыт и знания, хотя возможно сейчас делается не самым эффективным способом). Обязательный (критический) функционал по определению имеет уровень 1, за исключением тех случаев, когда клиент начинает заниматься новой деятельностью или сильно поменялись условия работы.
2. Возможности предлагаемой системы в данной области: -1 - нет требуемого функционала; 0 - есть функционал, но работает некорректно (внедрения такого функционала были неудачными или требовали больших переделок); 1 - в системе есть необходимый функционал (возможно, требует незначительных модификаций).
3. Знание консультантами исполнителя требуемого функционала предлагаемой системы: -1 - с таким функционалом не сталкивался; 0 - изучал функционал, но не внедрял; 1 - внедрял, но в другой системе; 2 - внедрял в предлагаемой системе, но данный функционал не заработал (или весь проект провальный, или неудачное внедрение именно этого модуля); 3 - внедрял в предлагаемой системе, внедрение удачное.
4. Знание консультантами исполнителя предметной области: -1 - о данной задаче ничего не знает; 0 - есть теоретические знания, на практике не сталкивался; 1 - работал (в штате или на проекте внедрения) в организации, где подобную задачу пытались решить, но решение оказалось неудачным (не заработало, работало неправильно); 2 - работал (в штате или на проекте внедрения) в организации, где подобную задачу успешно решали; 3 - работал (в штате или на проекте внедрения) в организации, где подобную задачу успешно решали, при этом специфика работы организации (имеющая отношение к данной задаче) такая же, как у клиента.

Максимальный совокупный балл по всем областям оценки равен 8 (вероятность успешного внедрения в заранее оговоренные сроки и стоимость близка к 1), минимальный -4 (есть высокая вероятность того, что данное требование вообще не получится выполнить).

* Выясняются прочие ограничения и требования к проекту внедрения.
* Анализируется возможность выполнения проекта внедрения в целом с учетом всех требований и ограничений. Требования к системе с оценкой возможностей внедрения 1 и ниже являются рискованными и существует высокая вероятность ошибки со сроками и стоимостью их внедрения, или же вообще провала внедрения данного функционала. Готов ли заказчик к внедрению системы с гарантированным внедрением только тех требований, которые получили высокую оценку возможности внедрения? Возможно, есть и другие препятствия - недостаточный срок или бюджет для такого объема работ или еще что-то.
* Разрабатывается предварительный план проекта. Весь требуемый функционал делится на три группы:
1. Будет внедрено к запуску системы в эксплуатацию.
2. Будет внедрено в течении некоего периода (скорее всего речь будет идти об 1-2 месяце) после запуска.
3. Нет жестких временных рамок по моменту внедрения.

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

* Проводятся переговоры с заказчиком и заключается рамочный договор с "предварительными" сроками, стоимостью и функционалом внедрения и алгоритмы изменения стоимости, сроков и функционала (если изменяются какие-либо условия). Также прописываются критерии успешности.
* Проводится "обучение" ключевого персонала заказчика - в стандартной базе проводится тренинг по выполнению основных бизнес процессов в системе. Вводятся новые товары, покупатели, меняются цены, выписываются документы продажи и т.п. В первую очередь очень подробно рассматривается обязательный для клиента функционал (работа с тестовыми данными и примерами) и фиксируются все замечания и пожелания. Также рассматривается остальной функционал - менее подробно и не предполагает выполнения тестовых заданий (в немалой степени по причине больших затрат времени на настройку тестовых примеров). Данный пункт опциональный и предлагается клиенту на платной основе. В результате клиент получает максимально полное представление о возможностях системы, которое можно получить без внедрения, и принимает обоснованное решение о внедрении. Исполнитель получает намного более точную картину требований по крайней мере по отношению к обязательному функционалу и может более точно просчитать сроки и стоимость.
* Если проводилось "обучение", заключается доп соглашение к договору, в котором более детально прописывается объем функционала, который будет внедрен к старту системы и в течении ограниченного времени после запуска, сроки и стоимость.

Внедрение функционала, необходимого для выполнения повседневных операций и запуск в эксплуатацию системы

* Составляется полный список всех справочников и остатков, которые должны быть введены в систему к запуску. Определяется, откуда и как будет получена вся необходимая информация к моменту старта и как она будет введена в систему. Начинаются работы по подготовке данных и методики их получения и загрузки (ETL).
* Составляется список сотрудников, которые должны начать работать с системой сразу с момента запуска (не обязательно точный список с фамилиями, можно указать должности, типы выполняемых операций и количество сотрудников для каждой должности).
*

Внедрение прочего обязательного функционала и часть желательного функционала (повышающего удобство работы / производительность труда)
Внедрение прочего функционала, входящего в проект
Поддержка
 

От s_ustinov:
 
Методология внедрения

Этапы проекта.

Диагностика

* Определение списка требований к системе, которые необходимо (желательно) выполнить в данном проекте. Список состоит из достаточно крупных блоков. В требования включаются только прикладные задачи, технические аспекты обсуждаются отдельно. Кроме прямо упоминающихся клиентом надо обязательно уточнить, какая функциональность имеющейся системы или систем используется. Все требования делятся на несколько групп:

1. Обязательный (критический) функционал, необходимый для выполнения обычных, повседневных операций (если используется некая система, он там обязательно есть). Пример - регистрация получения наличных денег, регистрация продажи товара и т.п.
2. Прочий обязательный функционал, который используется время от времени. Пример - формирование (получение) данных для расчета налогов.
3. Функционал, без которого можно обойтись, но выполнение некоторых операций будет очень неудобным и трудоемким. Пример - при возврате система сама автоматически проставляет ссылки на подходящие документы продажи, вместо того, чтобы пользователь вручную указывал нужные ссылки для каждой позиции в документе (при большом количестве возвратов существенно сказывается на производительности).
4. Функционал, который позволяет предприятию улучшить работу и/или добиться конкурентных преимуществ (обычно именно то, ради чего выполняется внедрение новой системы). Пример - учет товаров на складе в разрезе ячеек, расчет зарплаты сотрудников в зависимости от ряда показателей, поддержание оптимального уровня запасов на складах филиалов в автоматическом режиме и т.п.

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

* Составляется таблица наличия возможностей по внедрению каждого из требований. Существует 4 области оценки:
1. Знания и навыки клиента в данной области: -1 - не выполняют такие функции (нет опыта); 0 - выполняют, но результатом выполнения недовольны (возможно, неправильный подход или алгоритм - есть знание, как не получится (неправильно) делать); 1 - выполняют такие функции и результат удовлетворительный (есть необходимый опыт и знания, хотя возможно сейчас делается не самым эффективным способом). Обязательный (критический) функционал по определению имеет уровень 1, за исключением тех случаев, когда клиент начинает заниматься новой деятельностью или сильно поменялись условия работы.
2. Возможности предлагаемой системы в данной области: -1 - нет требуемого функционала; 0 - есть функционал, но работает некорректно (внедрения такого функционала были неудачными или требовали больших переделок); 1 - в системе есть необходимый функционал (возможно, требует незначительных модификаций).
3. Знание консультантами исполнителя требуемого функционала предлагаемой системы: -1 - с таким функционалом не сталкивался; 0 - изучал функционал, но не внедрял; 1 - внедрял, но в другой системе; 2 - внедрял в предлагаемой системе, но данный функционал не заработал (или весь проект провальный, или неудачное внедрение именно этого модуля); 3 - внедрял в предлагаемой системе, внедрение удачное.
4. Знание консультантами исполнителя предметной области: -1 - о данной задаче ничего не знает; 0 - есть теоретические знания, на практике не сталкивался; 1 - работал (в штате или на проекте внедрения) в организации, где подобную задачу пытались решить, но решение оказалось неудачным (не заработало, работало неправильно); 2 - работал (в штате или на проекте внедрения) в организации, где подобную задачу успешно решали; 3 - работал (в штате или на проекте внедрения) в организации, где подобную задачу успешно решали, при этом специфика работы организации (имеющая отношение к данной задаче) такая же, как у клиента.

Максимальный совокупный балл по всем областям оценки равен 8 (вероятность успешного внедрения в заранее оговоренные сроки и стоимость близка к 1), минимальный -4 (есть высокая вероятность того, что данное требование вообще не получится выполнить).

* Выясняются прочие ограничения и требования к проекту внедрения.
* Анализируется возможность выполнения проекта внедрения в целом с учетом всех требований и ограничений. Требования к системе с оценкой возможностей внедрения 1 и ниже являются рискованными и существует высокая вероятность ошибки со сроками и стоимостью их внедрения, или же вообще провала внедрения данного функционала. Готов ли заказчик к внедрению системы с гарантированным внедрением только тех требований, которые получили высокую оценку возможности внедрения? Возможно, есть и другие препятствия - недостаточный срок или бюджет для такого объема работ или еще что-то.
* Разрабатывается предварительный план проекта. Весь требуемый функционал делится на три группы:
1. Будет внедрено к запуску системы в эксплуатацию.
2. Будет внедрено в течении некоего периода (скорее всего речь будет идти об 1-2 месяце) после запуска.
3. Нет жестких временных рамок по моменту внедрения.

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

* Проводятся переговоры с заказчиком и заключается рамочный договор с "предварительными" сроками, стоимостью и функционалом внедрения и алгоритмы изменения стоимости, сроков и функционала (если изменяются какие-либо условия). Также прописываются критерии успешности.
* Проводится "обучение" ключевого персонала заказчика - в стандартной базе проводится тренинг по выполнению основных бизнес процессов в системе. Вводятся новые товары, покупатели, меняются цены, выписываются документы продажи и т.п. В первую очередь очень подробно рассматривается обязательный для клиента функционал (работа с тестовыми данными и примерами) и фиксируются все замечания и пожелания. Также рассматривается остальной функционал - менее подробно и не предполагает выполнения тестовых заданий (в немалой степени по причине больших затрат времени на настройку тестовых примеров). Данный пункт опциональный и предлагается клиенту на платной основе. В результате клиент получает максимально полное представление о возможностях системы, которое можно получить без внедрения, и принимает обоснованное решение о внедрении. Исполнитель получает намного более точную картину требований по крайней мере по отношению к обязательному функционалу и может более точно просчитать сроки и стоимость.
* Если проводилось "обучение", заключается доп соглашение к договору, в котором более детально прописывается объем функционала, который будет внедрен к старту системы и в течении ограниченного времени после запуска, сроки и стоимость.

Внедрение функционала, необходимого для выполнения повседневных операций и запуск системы в эксплуатацию

* Если не проводилось "обучение" - проводится и выявляются все нюансы, которые должны быть выполнены.
* Если объем работ по реализации нюансов превышает тот объем работ, что были зафиксированы в договоре - проводятся дополнительные переговоры с заказчиком и уточняются сроки, бюджет и объем внедряемого функционала.
* Составляется полный список всех справочников и остатков, которые должны быть введены в систему к запуску. Определяется, откуда и как будет получена вся необходимая информация к моменту старта и как она будет введена в систему. Выполняются работы по подготовке данных и методики их получения и загрузки (ETL).
* Составляется список сотрудников, которые должны начать работать с системой сразу с момента запуска (не обязательно точный список с фамилиями, можно указать должности, типы выполняемых операций и количество сотрудников для каждой должности).
* Производится установка системы на сервер.
* Выполняется настройка системы.
* Выполняются (при необходимости) доработки стандартного функционала.
* Готовятся краткие "Руководства пользователя" - инструкции по выполнению наиболее часто встречающихся операций. Готовятся на основе типовых инструкций с учетом модификаций и настроек конкретного внедрения.
* Тестируется возможность работы пользователей с системой - вход в систему и работа с терминалов в основном офисе, в удаленных офисах, печать документов, сохранение и открытие файлов и т.п.
* Производится тестовая загрузка справочников и остатков.
* Проводится тестирование системы и одновременно базовое обучение пользователей - как можно больше пользователей заходят в систему и пытаются выполнить свои обычные действия с тестовыми данными и остатками.
* Исправляются все обнаруженные недочеты с загрузкой справочников и остатков, настройками системы, руководствами пользователя и решаются прочие выявленные проблемы.
* Выполняется рабочая загрузка справочников и остатков и проверяется корректность и полнота загруженных данных.
* Запуск системы в эксплуатацию - система начинает реально использоваться в бизнес процессах.
* Обучение пользователей работе с обязательным функционалом, использующемся в повседневной работе (обычно от 2-3 дней до недели). Обучение заключается в помощи при выполнении операций, когда у пользователей возникают затруднения.
* Подписание актов с заказчиком и получение оплаты.

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

Внедрение прочего обязательного функционала и часть желательного функционала (повышающего удобство работы / производительность труда)

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

* Обучение пользователей использовать относительно редко необходимые функции - различные отчеты и обработки, выполнение разных настроек системы (которые им доступны), выполнение действий, которые необходимо делать время от времени, а не постоянно и т.п.
* Выполняются различные настройки, которые не были сделаны на предыдущем этапе - настройки отчетов, прав пользователей, более тонкая настройка интерфейсов и т.п.
* Внедряется прочий обязательный функционал, не внедренный к моменту старта (внедряется стандартный функционал и/или выполняются доработки).
* Внедряется функционал, который решает наиболее критичные проблемы с трудоемкостью и удобством (чаще всего речь идет о доработках). Через неделю после старта пользователи выскажут много претензий и пожеланий. Надо проанализировать все пожелания, отбросить те, которые связаны с проблемами привыкания к другой идеологии работы и к непривычному интерфейсу, и из оставшихся выбрать наиболее существенные. Список подлежащих решению проблем и пожеланий согласовывается с заказчиком.
* Выполняются работы по техподдержке.
* Подписание актов с заказчиком и получение оплаты. Стоимость формируется за счет трех типов работ:
1. Внедрение обязательного функционала, оговоренного в начале проекта и обучение пользователей.
2. Услуги техподдержки.
3. Реализация дополнительных пожеланий, возникших по результатам первых дней эксплуатации.

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

Внедрение прочего функционала, входящего в проект

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

* Анализ. С сотрудниками заказчика подробно обсуждаются требования. Так как концентрируются на одной задаче, легче выявить все нюансы. Также очень помогает то, что пользователи уже имеют опыт работы в системе и понимают, в каком "окружении" будет выполнятся внедряемый функционал.
* Согласование. Уточняется на основе тщательного анализа требуемый объем работ и с заказчиком согласовывается уточненная стоимость и сроки внедрения данного функционала (предварительная оценка была сделана на этапе диагностики).
* Разработка. Выполняется настройка системы и/или выполняются доработки.
* Тестирование, исправление ошибок и обучение. Совместно с пользователями проверяется корректность работы внедряемого функционала. При необходимости вносятся исправления. Параллельно выполняется обучение пользователей использованию нового функционала.
* Ввод в эксплуатацию. Функционал начинает использоваться в работе.
* Подписание акта с заказчиком и получение оплаты.

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

Также во время этого этапа выполняются работы по техподдержке.

Поддержка и дальнейшее усовершенствование системы

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