Пример таблицы ежедневной занятости специалистов
┌────────────┬───────────┬──────────┬────────────┬────────────┬────────────┬─────────┬────────┬────────┐
│ Сотрудник │ 9-10 │ 10-11 │ 11-12 │ 12-13 │ 14-15 │ 15-16 │ 16-17 │ 17-18 │
├────────────┼───────────┼──────────┴────────────┴────────────┼────────────┼─────────┴────────┴────────┤
│Специалист │Ожидание │Обслуживание клиентов │Обработка │Ожидание │
│операционно-│(30 мин).│ │документов. │ │
│го зала │Подготовка │ │Контроль и│ │
│ │выписок │ │подготовка к│ │
│ │клиенту │ │отправке │ │
|
|
|
├────────────┼───────────┼──────────┬────────────┬────────────┼────────────┼─────────┬─────────────────┤
│Экономист │Ожидание │Оформление│Формирование│Оформление │Ожидание │Контроль │Ожидание │
│бухгалтерии │ │входящих │документов и│собственных │ │отправки │ │
│ │ │платежей │отчетов │платежей │ │платежей │ │
│ │ │ │закрытия дня│банка │ │ │ │
├────────────┼───────────┼──────────┼────────────┼────────────┴────────────┼─────────┼─────────────────┤
|
|
|
│Специалист │Прием │Ожидание │Закрытие дня│Ожидание │Отправка │Ожидание │
│отдела │информации │ │в АБС │ │платежей │ │
│автоматиза- │из РКЦ.│ │ │ │ │ │
│ции │Печать │ │ │ │ │ │
│ │выписок по│ │ │ │ │ │
│ │счетам │ │ │ │ │ │
└────────────┴───────────┴──────────┴────────────┴─────────────────────────┴─────────┴─────────────────┘
"Рис. 19. Пример графика ежедневной занятости специалиста"
|
|
|
Предпроектное обследование
Обычно необходимость предпроектного обследования не вызывает сомнения. Если компания-разработчик объявляет его частью работ по внедрению, то отказать ей в этом невозможно, в противном случае с разработчика будет снята вся ответственность за возникающие проблемы. Если же для помощи приглашены сторонние консультанты, то предпроектное обследование и разработка на их основе перспективной схемы работы организации, а также плана перехода являются объектом их работы.
Однако результаты предпроектного обследования могут существенно различаться в зависимости от того, кто и по каким методикам его проводит. Результатами наиболее полного предпроектного обследования должны быть следующие документы:
* описание текущей деятельности организации и информационной системы. Данное описание становится более наглядным и полезным, если выполнено в графическом формате с текстовыми пояснительными записками;
* перечень документов, участвующих в документообороте, их состояние и печатные формы;
* альбом отчетности, формируемой в организации;
* перспективная модель организации после реструктуризации информационной системы, включая оптимизированную систему документооборота. Также необходимо провести полную экономическую оценку проекта;
|
|
|
* подробный план перехода от текущей модели к перспективной с указанием ресурсов, сроков и исполнителей;
* список доработок информационной системы, утвержденный к внедрению.
Учитывая большой объем предстоящих работ и необходимость проверенных методик для проведения подобного обследования, наиболее логично поручить их либо консалтинговым компаниям, либо специализированному подразделению компании-разработчика.
В ряде случаев можно обойтись сокращенным предпроектным обследованием. Это так называемая двухшаговая реализация проекта. Первый шаг - простая смена ядра системы без расширения функционала и оптимизации документооборота, второй шаг - реализация новых требований на уже работающем новом ядре. Данный подход более стабилен и снижает угрозу работоспособности организации в целом, однако требует большего времени. В этом случае в качестве предпроектного обследования достаточно описания текущего функционала информационной системы. Обследование может быть выполнено либо сотрудниками компании-разработчика, либо сотрудниками кредитной организации.
Несмотря на то что предпроектное обследование требует определенных финансовых затрат, по его результатам рекомендуется сделать дополнительное подтверждение решения о начале реализации проекта с учетом нового понимания объема работ, скорректированного бюджета и ожидаемого эффекта. Обоснованный отказ от проекта на данном этапе будет понят как акционерами, так и высшем руководством. Отказ от проекта на последующих этапах будет означать его провал и, как следствие, санкции для менеджеров и исполнителей.
Одним из важнейших результатов предпроектного обследования, независимо от выбранного сценария, должен стать план проекта, который настолько важен, что ему будет посвящена отдельная глава.
Составление плана работ
План работ строится на основе согласованного сторонами списка задач. Поэтому, прежде чем составлять план, они должны быть подготовлены. Обычно это происходит на той же стадии предпроектного обследования. Естественно, учесть все аспекты еще только начатых работ, их глубину и реальную трудоемкость невозможно, но тем не менее план проекта в первом приближении может и должен быть составлен именно на этой стадии. Впоследствии он будет расширяться, детализироваться, возможно, пересматриваться, но это не отрицает необходимости его наличия и согласования с самого начала проекта.
При составлении плана работ почти все участники проекта стремятся, чтобы их участие было как можно меньше. Исключением могут являться некоторые сотрудники отдела автоматизации, которые хотят, чтобы работа была как можно более интересной, желательно с решением "сложных" задач, объемной разработкой новых программ и покупкой оборудования. Как правило, эти люди контролируемы, но о них не стоит забывать. С другой стороны, и пользователи, заказчики зачастую пытаются автоматизировать операции, автоматизация которых не имеет никакого смысла, например операцию, которая возникает раз в полгода.
Реалистичность объема проектных задач и сроков - это первый экзамен, который должен успешно сдать менеджер проекта при начале работ и закрепить его в плане проекта. Самое легкое - отвечать на все предложения: "Мы это сделаем и очень скоро", ведь проект только начинается. Но ответственный руководитель проекта должен быть пессимистом, учитывать опыт других проектов и очень реалистично оценивать имеющиеся силы и ресурсы и уметь говорить "нет", аргументируя свою позицию. Менеджер проекта, видя перед собой постоянно основную цель проекта, должен уметь находить компромисс и убеждать все стороны.
Как же может быть сокращен и адекватно оценен объем требований? Основным приемом снижения объемов работ является поиск работающих прототипов. Если требуются новые отчеты при расчете налогов, надо выяснить, нет ли аналогичных отчетов в других областях. Если требуется организация новой услуги, надо посмотреть, как она реализована в других банках. А если ее там нет, то еще раз проанализировать ее необходимость.
Общий алгоритм поиска прототипа заключается в следующем. Сначала идет поиск аналогов решения всей задачи. Если их нет, то формулируется более общая задача и ищутся подобные решения. И так до тех пор, пока не будет найдено ближайшее по смыслу работающее решение. Затем определяются доработки к нему. Например, если нужна система межфилиальных расчетов, за основу можно взять систему расчетов в РКЦ или SWIFT, или систему "банк-клиент". Всегда есть аналогичные системы, доработка которых существенно дешевле и надежнее, чем разработка системы с нуля. Кроме того, если в приведенном примере система расчетов будет создаваться на базе системы "банк-клиент", то побочным эффектом будет расширение предлагаемого клиентам сервиса.
Другой универсальный механизм оценки адекватности требований и оправданности их автоматизации - это финансовая оценка. По каждой потенциальной задаче руководителем проекта может быть сделана оценка требуемого времени специалистов, учтены все необходимые другие ресурсы и в конечном счете получена оценка стоимости выполнения этой отдельной задачи. Она должна быть сравнима со стоимостью поддержки данной операции в "ручном" или полуавтоматическом режиме. Не очень умно автоматизировать получение отчета, затраты на ручное выполнение которого в десятки раз ниже стоимости доработки системы. Окончательное суждение в подобных вопросах должно принадлежать представителям бизнеса.
Рассмотрим теперь технические вопросы составления самого плана проекта. Самая лучшая формула, которой можно при этом руководствоваться, - это "Плохой план проекта сегодня лучше, чем хороший завтра". Многие руководители проектов пишут планы месяцами, они составляют десятки страниц. Но, к сожалению, их никак не могут дописать и согласовать. План может быть объемным, но 2-3-страничный план, особенно на начальных стадиях, не только является допустимым, но и более предпочтительным.
Из того, что обязательно должно быть в плане, - это ключевые точки (обучение, согласование детальных требований, презентация и корректировка прототипа, завершение разработки, начало и конец тестирования, исправление замечаний, начало и окончание пользовательского тестирования, дополнительное обучение, начало опытной эксплуатации, переход на промышленную эксплуатацию) с точным указанием времени их наступления. Также в плане должны найти свое отражение перечень основных задач и их взаимозависимость, распределение задач по этапам, ресурсное обеспечение и ответственные лица. Если все это есть и согласовано со всеми сторонами, то план достигает своей цели.
Ниже представлен пример планов проекта, выполненных в традиционном виде с помощью специального программного продукта MS Project, и более простой вариант плана проекта, подготовленный с использованием MS Excel (рис. 20 и 21).
"Рис. 20. План проекта в виде Гант-диаграммы, подготовленный в MS Project"
Детальная постановка задачи
Следующий этап - детальная постановка задачи. Корректная постановка задачи - уже повышение вероятности успеха и сокращение затрат на проект на 30-50%. Четкие ответы на вопрос "Что надо?" часто сразу дают ответ на вопрос "Как делать?". Особенностью российских правил учета является тот факт, что изменения в них часто носят весьма глобальный характер, в результате четкого понимания всех изменений на этапе начала проекта нет ни у кого в организации. Для решения этой проблемы используются приемы, которые рассмотрены ниже.
Описание глобальной цели проекта включает ответы на вопросы "Зачем?" как для внешней среды (Зачем ЦБ РФ издал такую инструкцию?), так и самой организации и ее подразделений (Зачем организации реализовывать этот проект?). Вариантов ответов на последний вопрос может быть несколько: "Чтобы организацию не оштрафовали" (самый неудачный ответ), "Данная инструкция позволит снизить операционные риски от совершения операций" и т.д. Анализ ответов позволит не только более точно понимать детали изменений, но и прогнозировать дальнейшие дополнения и исправления.
"Рис. 21. Упрощенный план-график проекта"
Создание единого информационного пространства проекта. В простейшем варианте оно представляет собой директорию, в которой все участники проекта записывают имеющуюся у них информацию и соображения по поводу решаемой задачи. Более сложным вариантом является организация интранет-конференции.
Использование ролевого моделирования процесса подразумевает обыгрывание несколько раз бизнес-процесса всеми его участниками с обязательной регистрацией всех выполняемых действий и пожеланий:
┌────────────────────────┐ ┌─────────────────────────────┐
│Сотрудник бухгалтерии: │ │Сотрудник отдел отчетности: │
│Я регистрирую документ│ │Я формирую отчет группировки│
│данного типа в АБС.│ │платежей по статьям расхода│
│Ввожу следующие поля: │ │за период. В качестве│
│СЧЕТ ПО ДЕБЕТУ, СЧЕТ ПО│ │параметра отчета я должен│
│КРЕДИТУ, СУММУ,│ │определять интервал дат.│
│НАЗНАЧЕНИЕ... │ │Отчет должен иметь следующую│
│ │ │форму: │
│ │ │ │
│Пометка: надо вводить│ │┌────┬─────┬────┬─────┬─────┐│
│еще и статьи расхода....│ ││ │ │ │ │ ││
│ │ │├────┼─────┼────┼─────┼─────┤│
│ │ ││ │ │ │ │ ││
│ │ │├────┼─────┼────┼─────┼─────┤│
│ │ ││ │ │ │ │ ││
│ │ │└────┴─────┴────┴─────┴─────┘│
└────────────────────────┘ └─────────────────────────────┘
Данный прием моделирования позволяет максимально использовать имеющийся человеческий капитал, поскольку каждый участник строит свой бизнес-процесс самостоятельно, а общий контроль осуществляет руководитель и представители других подразделений.
Описанные приемы помогут группе более точно понять и написать техническое и бизнес-задание проекта. В бизнес-задании описываются основные функциональные требования, техническое - отражает более детальную информацию, особенности, включая параметры и подходы к реализации. Иногда они подготавливаются разными людьми, но гораздо чаще представляют единый документ, который готовится одним человеком - аналитиком. Далее мы не будем делать различий между этими документами и понятиями.
Следует помнить, что, если точного задания не получится, придется давать системе, реализующей проект, дополнительную гибкость. Но реализация универсальной, гибкой бизнес-функции требует в несколько раз больше ресурсов на разработку и сопровождение, чем статичное решение.
Кроме того, рекомендуется вести разработку двух заданий, которые условно можно назвать: "Программа-минимум" и "Программа-максимум". В первом варианте нужно описать минимальные изменения в организации по сравнению с текущим положением дел, достаточные для реализации основной цели. Второй документ должен составляться с учетом всех пожеланий и перспектив. Как правило, в конце проекта будет реализован некоторый промежуточный вариант. Имея установленный проект бюджета, группа сначала реализует только самые необходимые требования (на это бюджета, как правило, хватает), а потом либо будет дополнять данное решение новыми возможностями, либо аргументирует прекращение работ и возьмет на себя ответственность за это.
В любом случае при постановке задачи, как и везде, вредны крайности. Многие проекты были загублены чересчур грамотными аналитиками, которые месяцами составляли задания, исчисляемые сотнями страниц. Потом сами же с трудом могли понять, что они имели в виду, настолько запутана и сложна была задача или ее описание. Поверхностность также вредна. Исходя из практического опыта, можно сказать, что ориентирами "золотой середины" могут являться параметры объема работ по подготовке технического задания, представленные в табл. 15.
Таблица 15
Дата добавления: 2019-01-14; просмотров: 204; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!