Читаем Журнал «Компьютерра» № 8 от 28 февраля 2006 года полностью

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

Обычно Исполнитель хотя бы часть дополнительных веток БП описывает. Но часто Заказчик не замечает, что некоторые ветки были упущены. Это может происходить по нескольким причинам, часть которых является следствиями ошибок, допущенных на этапе формирования проектной команды Заказчика:

1. Специалистами Заказчика, ответственными за приемку работ, являются ИТ-специалисты, и их квалификации недостаточно для оценки качества документа.

2. Ответственность своих специалистов оценивается Заказчиком неадекватно. То есть человек, принимающий основные решения по проекту общей стоимостью 500 тысяч долларов, может иметь зарплату 1 тысячу долларов.

3. Ответственность за результат работы отодвинута во времени на длительный срок. Если описание БП будет неправильным, это станет заметно только через несколько месяцев.

4. У специалистов заказчика есть другие сложные задачи, вне данного проекта, ответственность по которым сиюминутная и дорогая.

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

6. Бизнес-процессы могут измениться к моменту начала внедрения.

Если при правильной организации приемки работ с причинами 1, 2, 4, 5, 6 можно и нужно бороться, то причина 3 является неотъемлемой частью этапа описания БП.

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

2.2. Техническое задание на проект

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

Принимается этот документ почти так же, как принимается описание бизнес-процессов. Не исключено, что Заказчик заставит Исполнителя включить в задание еще пару пунктов, которые неявно упоминались в договоре. Специалисты Заказчика довольны – им удалось настоять на своем. Исполнитель доволен – этап закрыт.

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

2.3. Настройка системы, описание доработок

Настройка системы требует грамотного консультанта. Это уже технология, и ясно, за что платятся деньги – у Заказчика нет специалиста, который сможет это сделать. Описание доработок – документ еще более сложный. Консультант, хорошо знающий систему, определяет, что из описанного в техническом задании системе по силам, а что потребует написания дополнительных программ.

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

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

2.4. Доработка системы

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

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

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

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

Перейти на страницу:

Похожие книги

Первые шаги с Windows 7. Руководство для начинающих
Первые шаги с Windows 7. Руководство для начинающих

Просто и понятно для начинающих пользователей описана операционная система Windows 7 и ее новые возможности. Рассказано, как установить Windows 7 (в том числе на нетбук), как полностью использовать новые возможности графического интерфейса, как работать с файлами и стандартными программами. Отдельное внимание уделено вопросам работы в Интернете: настройке доступа, описанию популярных программ для работы в Интернете, обеспечению безопасности. Подробно рассмотрены мультимедиапрограммы Windows Media, Windows Media Center, DVD-студия Windows, прожиг CD/DVD средствами операционной системы. Даны практические рекомендации использования системы восстановления Windows 7, позволяющей в большинстве случаев обойтись без переустановки операционной системы в случае ее сбоя.Прилагаемый компакт-диск содержит видеокурс по основам работы в Windows 7.

Денис Николаевич Колисниченко , Денис Н. Колисниченко

Зарубежная компьютерная, околокомпьютерная литература / Прочая компьютерная литература / Книги по IT
Внедрение SAP R/3: Руководство для менеджеров и инженеров
Внедрение SAP R/3: Руководство для менеджеров и инженеров

Это практическое всеобъемлющие руководство было написано специально для тех, кто выбирает стратегию внедрения SAP в организации. «Внедрение SAP R/3: руководство для менеджеров и инженеров» объясняет, что означает понятие «эпоха ERP», почему информация является одним из ключевых ресурсов предприятия, как SAP способствует росту конкурентоспособности компании, а также преимущества методологии ASAP в планировании и использовании ресурсов при внедрении SAP. Подход к ERP-системам, используемый в данной книге, будет крайне полезен менеджерам и специалистам, которым необходимо представить высшему руководству своих компаний основания для внедрения SAP; кроме того, данная книга будет весьма полезной тем, кто занимается проектами SAP или планирует такой проект в ближайшем будущем. Для тех читателей, кто непосредственно занят в проектах SAP, эта книга станет надежным руководством и поможет внести существенный вклад в развитие проекта.

Вивек Кале

Зарубежная компьютерная, околокомпьютерная литература / Прочая компьютерная литература / Книги по IT