Темы лекций: Классификация и виды ис, способы автоматизации. Для позготовки следует ознакомиться со следующим материалом
| Вид материала | Документы |
- Курс лекций содержит принципиальные положения и основные исходные сведения для подготовки, 10.16kb.
- Концепция маркетинга Классификация маркетинга > Субъекты маркетинга 10. Виды маркетинга, 1942.83kb.
- Рекомендации для проведения занятий по темам, 164.18kb.
- Тематические планы лекций Темы лекций по терапевтической стоматологии для студентов, 733.5kb.
- Комплекс технических и программных средств, предназначенный для автоматизации подготовки, 1459.97kb.
- План лекций по биоорганической химии для студентов 1 курса медицинского факультета, 26.83kb.
- Реферата актуальна в связи с постоянно растущим спросом на различные виды очков, включая, 101.64kb.
- Тексты лекций по курсу «Основы рекламного дела», 247.42kb.
- Тексты лекций по курсу «Основы рекламного дела», 466.44kb.
- Календарный план (весенний семестр 2010/2011 учебного года) лекций старшего преподавателя, 64.7kb.
Глава 8
Внедрение систем
Внедрение систем — это комплекс специфических задач, выполне-
ние которых позволяет добиться реальной эксплуатации решения в орга-
низации. Другими словами, это внедрение изменений, которое мы уже
разбирали выше.
В общем случае процесс внедрения состоит из ряда организацион-
ных действий, подготовительных работ технического и административ-
ного плана тестовой (опытной) и промышленной эксплуатации. Далее
мы рассмотрим эти составляющие.
Особенности внедрения
Внедрение, пожалуй, — самый ответственный момент проекта за-
мены информационной системы. Это связано с рядом причин.
Во-первых, как мы уже отмечали при рассмотрении управления из-
менениями, это всегда наиболее сложная составляющая работы.
Во-вторых, даже если на предыдущих стадиях была создана очень
хорошая информационная система, до тех пор, пока она не внедрена,
ее ценность равна нулю. Часто менеджеры стараются до бесконечнос-
ти совершенствовать продукт, наслаждаясь им в узком кругу програм-
мистов и ИТ-экспертов, не понимая, почему ни у кого больше их много-
летние изыскания не вызывают оптимизма.
В-третьих, внедрение — это не экзамен, а нечто большее, и поэтому
даже блестяще оттестированные и подготовленные системы, сдавшие
все «экзамены», могут не подойти по тем или иным причинам. Думать,
что заранее можно предвидеть все проблемы, недальновидно. Во вре-
мя внедрения все проблемы, конфликты, которые не были решены ра-
нее, были забыты или решены неправильно, отложены, недодуманы,
скрыты, всплывают практически в один момент, требуя непомерных
профессиональных знаний и личных усилий всех участников проекта.
Организационные действия
На практике часто бывает так. Внедрение хорошо подготовлено:
проведены многочисленные выверки данных, тестирование и многие
другие, важные для внедрения, работы (о чем мы еще будем говорить
далее). Но почему-то внедрение срывается, ком проблем растет с такой
скоростью, что в один прекрасный момент большинству становиться ясно, что система не может быть внедрена. Проектная команда, менедж-
мент теряют веру, количество проблем от этого возрастает еще боль-
ше, и в конечном счете проект останавливается или приостанавливает-
ся высшим руководством.
Можно ли избежать этого? Ответ практикующих менеджеров про-
ектов в 99,9% случаев — «да». Набор инструментов для достижения
такого результата достаточно уникален и индивидуален и является во
многом профессиональным ноу-хау (Know-How) руководителя проек-
та. Мы же рассмотрим некоторые основные составляющие таких орга-
низационных действий, которые позволяют сделать даже проблемное
внедрение успешным.
Снятие противоречий и конфликтов. Первый вопрос, который
необходимо прояснить, — всем ли нужно внедрение как в самой орга-
низации, так и среди подрядчиков? Кому оно невыгодно по тем или
иным причинам? Кто против в настоящее время или был против на ран-
них стадиях проекта? Кто не принимал участия? Даже это может быть
важно, потому что успех одного руководителя может автоматически
снижать авторитет тех, кто не верил в исход проекта или был против
него. Не стоит искать конфликты только среди руководства, они могут
быть и на более низком уровне и при этом иметь очень большое значе-
ние. Задача руководителя проекта состоит в том, чтобы не только най-
ти все эти центры противоречий и конфликтов, но и свести их на нет
или по крайней мере добиться, чтобы их влияние на проект было мини-
мальным.
Прояснение недопониманий и выработка согласованных под-
ходов. Даже там, где нет предпосылок для конфликта, он может воз-
никнуть по причине недопонимания. Внедрение является сложной за-
дачей, и поэтому неминуемо в процессе работ, а особенно на их завер-
шающей стадии, возникают такие ситуации, когда, не решаясь задать
лишний вопрос, те или иные участники процесса просто не понимают
смысл определенных действий или понимают его неправильно. Задача
руководителя проекта — не только добиться того, чтобы количество
таких недопониманий было минимальным, его задача также состоит в
том, чтобы инициировать процедуры согласования позиций, их обсуж-
дения и понятного и доступного формального закрепления в бумажной
форме. Он должен как можно больше задавать вопросов всем участни-
кам, чтобы добиться в конце концов одинаковых и согласованных по-
зиций и полного понимания участниками и заинтересованными сторо-
нами того, что происходит.
Прояснение формальной (юридической) позиции — тоже важ-
ная составляющая организационных действий. Выполненная до начала
внедрения, посредством дополнительного анализа существующих фор-
мальных или договорных отношений между сторонами, она способна
оказать реальную помощь в реализации двух предыдущих пунктов. Ини-
циатором этой работы должен выступать руководитель проекта. При
выявлении неясностей в формальных отношениях сторон их проясняют
обязательно до начала внедрения, чтобы не приостанавливать его или
не служить еще одним дополнительным риском.
Онлайн-менеджмент и контроль. Во время внедрения осуществ-
ляются постоянный надзор и контроль со стороны высшего менедж-
мента за происходящим. Он должен быть организован в онлайн-режи-
ме, то есть участники проекта, его руководство имеют приоритетное
право на взаимодействие с высшим менеджментом организации. Конт-
роль должен осуществляться на оперативной и регулярной основе. За-
седания управляющего комитета должны проводиться чаще, чем при
обычной работе, и не реже одного раза в неделю. Не исключен и еже-
дневный вариант. Формальная отчетность и информация по ходу про-
екта должна быть доступна всем заинтересованным сторонам также на
оперативной основе.
Оперативный анализ рисков. Отдельно руководителем проекта с
помощью ведущих экспертов по основным областям ведется анализ
рисков внедрения. Его форма должна быть простой и понятной. Это
может быть просто текстовый список проблем, где указывается следу-
ющая информация: кто инициировал занесение проблемы в список, ее
номер (если есть), суть проблемы, ответственный за решение, дата ре-
гистрации проблемы, дата решения, кратко основные действия по ре-
шению, приоритет и текущий статус (решена или нет). Такой список очень
помогает руководителю проекта не забывать обо всех возникающих
проблемах и в то же время является инструментом контроля и давления
на исполнителей, ответственных за решение.
Мотивация персонала на достижение результата. Возможно, са-
мый главный пункт — это мотивация всех участников проекта и прежде
всего его непосредственных работников на достижение результата. Мы
уже останавливались на основных подходах по мотивации, когда рас-
сматривали управление ИТ-персоналом, поэтому не будем здесь повто-
ряться.
Широкое информирование заинтересованных сторон. Отдель-
ная задача в ходе внедрения — информирование всех заинтересованных сторон, включая обычных сотрудников организации, о ходе и ста-
тусе работ. При недостатке информирования проект обрастает слуха-
ми, которые будут очень мешать в работе. С другой стороны, поддерж-
ка со стороны всей организации очень полезна для работы, является
дополнительным источником мотивации. Но это возможно только при
наличии информации и понимания, в противном случае отношение бу-
дет очень негативным.
Качественное и детальное планирование и обеспечение ресур-
сами. Планирование важно всегда, но на этапе внедрения оно имеет
повышенное значение. Помимо этого целесообразно иметь небольшой
резерв ресурсов, которые могут быть временно сняты с других работ
или привлечены на отдельные участки со стороны. Все стандартные
методики управления ресурсами, такие, как сетевое планирование, ис-
пользование методики критического пути, должны использоваться ру-
ководителем проекта для получения информации и оперативного при-
нятия решений по переброске ресурсов или их увеличению.
Подготовка к внедрению
Существенная часть временных затрат при внедрении систем долж-
на быть потрачена на подготовительные работы технического и адми-
нистративного характера. Данные работы включают:
• доработку программного обеспечения и его тестирование;
• подготовку компьютерной техники, приведение ее к необходимым техническим требованиям разработчика;
• обучение пользователей и администраторов системы;
• разработку конверторов данных из существующей системы в новую, разработку и тестирование методик контроля правильности переноса данных;
• разработку руководств пользователей и администраторов системы;
• разработку инструкций на случай технологических сбоев в системе.
Окончанием подготовительного периода должна стать тестовая эк-
сплуатация системы с участием конечных пользователей. В случае не-
больших организаций и незначительного документооборота возможна
параллельная работа обоих систем. Однако в крупных организациях
параллельное ведение — весьма затратное и беспокойное мероприя-
тие. В этом случае лучше применить поэтапное тестирование различ-
ных составляющих с участием сотрудников соответствующих подраз-
делений.
По результатам опытной эксплуатации рекомендуется составить акт,
в котором регистрируются все недоработки системы, а также сроки их
устранения. При этом в случае наличия критичных недостатков, спо-
собных привести к технологическому сбою в работе организации, пос-
ле их устранения необходимо провести повторное тестирование всех
составляющих системы. Таким образом, после полнофункционально-
го тестирования до начала рабочей эксплуатации системы вводится
мораторий на внесение изменений в систему. Это делается для того,
чтобы в результате внесения исправлений не были порождены новые
ошибки.
Начало рабочей эксплуатации
Начало рабочей эксплуатации является самым критическим момен-
том в проекте. Фактически успешный старт и работа в системе хотя бы в
течение нескольких дней означают успех проекта. Конечно, наличие
большого количества недоработок, кажущиеся неудобства в работе,
периодические сбои не позволяют сказать об этом сразу, но все эти
проблемы намного более просты в решении, чем поддержание двух ин-
формационных систем и постоянная синхронизация данных в них.
Но начало рабочей эксплуатации и, как следствие, отказ от поддер-
жки старой системы не могут основываться только на желании это сде-
лать. Малейший сбой приводит к откату к предыдущему состоянию, к
возврату эксплуатации старой системы, поскольку ни один руководи-
тель не возьмет на себя ответственность продолжать эксперимент, ког-
да, например, у него не проходят обработку клиентские платежи или
неправильно рассчитываются процентные ставки по депозитам более
чем в течение 10 минут.
В зависимости от размера организации возможны два варианта пе-
рехода на рабочую эксплуатацию. Для организации с количеством со-
трудников до 100 человек, как правило, применяется тотальный пере-
ход. Все пользователи в определенный день (обычно пятницу, чтобы
было время для устранения ошибок) начинают работу в новой системе.
Основными показателями успешного перехода на новую систему явля-
ются отсутствие задержек приема документов у клиента, своевремен-
ная отправка платежей, получение правильного баланса.
В случае, если внедряемая система решает большой спектр задач,
количество пользователей более 100, необходим поэтапный переход.
Он может осуществляться в следующей последовательности:
— запуск интерфейса взаимодействия с внешними платежными си-
стемами, маршрутизация платежей филиалов;
— формирование баланса и прочей ежедневной и оперативной от-
четности;
— ввод простейших платежных документов в систему пользовате-
лями, ведение расчетно-кассового обслуживания;
— учет сложных операций (покупка-продажа валют);
— автоматическое начисление процентов и платы за обслуживание;
— формирование документопотока в соответствии с перспективной
моделью организации, изменение обязанностей сотрудников, участву-
ющих в расчетно-кассовом обслуживании клиентов и собственных пла-
тежей банка;
— учет операций физических лиц;
— учет внутренних операций банка: расчет зарплат, ведение хозяй-
ственных договоров, учет основных средств;
— учет и ведение кредитов банка;
— учет прочих операций банка, включая торговые операции на бирже.
Такая последовательность позволяет минимизировать последствия возможных сбоев и дает время команде внедрения сосредоточиться на одной задаче, а не распылять свои силы на решение всех проблем.
Завершение проектов
Переход на рабочую эксплуатацию системы обычно заканчивается
подписанием акта о проделанной работе. Однако большое количество
недоработок и недовольство пользователей нельзя назвать успешным
завершением. Таким образом, взаимодействие с разработчиками не
заканчивается рабочей эксплуатацией, а переходит в новую стадию—
сопровождение. Не стоит требовать от разработчиков немедленного
устранения всех недочетов. Лучше в течение некоторого времени дать
пользователям поработать с новой системой, почувствовать ее возмож-
ности и преимущества перед старой. И только после того, как отрица-
тельные эмоции улягутся и пользователи смогут более квалифициро-
ванно говорить о достоинствах и недостатках нового решения, необхо-
димо провести их опрос и составить план устранения действительно
важных недоработок. При этом часть проблем к этому времени смогут
снять сотрудники автоматизации банка. А остальные решит компания
разработчика, которая, получив аргументированные и понятные претен-
зии, не сможет отказать своему клиенту.
Таким образом, система начнет работать в свою полную силу, все
больше и больше приближаясь к тому идеалу, о котором думали менед-
жеры и специалисты банка перед началом проекта, когда рассматрива-
ли, каким образом изменить технологию работы банка и какие ново-
введения ему нужны.