Документационное обеспечение управления

Скачать 2.25 Mb.

Название	Документационное обеспечение управления
страница	30/30
Тип	Руководство

rykovodstvo.ru > Руководство эксплуатация > Руководство

1 ... 22 23 24 25 26 27 28 29 30

Внедрение в масштабах предприятия.

К моменту начала работ по этапу «Внедрение в масштабах предприятия» командой проекта уже получены следующие результаты:

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

Можно начинать работы по полномасштабному внедрению системы электронного документооборота. Важно понимать, что внедрение не сводится к простой закупке оборудования, инсталляции и настройке программного обеспечения. На самом деле, проблемы, которые приходится решать в рамках внедрения СУД, гораздо сложнее и разнообразнее. В методологии AVM под «Внедрением в масштабах предприятия» подразумевается проведение всего комплекса мероприятий, необходимых для развертывания не только самой СУД, но и инфраструктуры поддержки для нее.

Этапы внедрения.

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

2. Подготовка, согласование и утверждение концепции (плана) внедрения. Концепция внедрения содержит следующие положения:

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

3. Повышение квалификации членов команды внедрения.

4. Планирование архитектуры системы и топологии сети (утверждение нового технологического ландшафта).

На этом этапе новый технологический ландшафт, предложенный на этапе «Инновация процессов», прорабатывается более детально, исходя из прогнозируемой нагрузки на ИС, ожидаемого числа пользователей, объема хранимой и обрабатываемой информации, требований к надежности и доступности. Архитектура системы рассматривается с точки зрения логического и физического уровня.

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

На физическом уровне решаются 3 основных вопроса:

1) выбор программно-аппаратной платформы для серверов и рабочих станций. При этом учитываются потребности в объеме оперативной памяти, емкости жестких дисков, поддерживаемые сетевые протоколы, версии операционных систем. На выбор программно-аппаратной платформы влияет также наличие готовой техники, квалифицированного персонала, финансовых ресурсов;

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

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

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

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

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

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

Технологии. Техническая поддержка может осуществляться как в синхронном (Hot Line), так и в асинхронном (Help Desk) режимах. Для технической поддержки могут применяться программные продукты других классов – средства автоматической регистрации звонков, базы знаний по продуктам и т.д.

6. Управление конфигурацией.

Управление преобразованиями

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

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

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

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

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

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

Мероприятия управления преобразованиями:

1. Оценка степени готовности к изменениям.

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

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

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

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

2. Анализ вкладов участников процесса.

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

Возможные инвестиции в процесс изменений («Чем я могу помочь?»);
Ожидания от инвестиций («Что я буду иметь в результате?»);
Возможные сомнения и опасения («Чем это мне грозит?»).

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

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

3. Интеграция корпоративных знаний.

Что же такое знание и в чем его отличие от информации и данных?

данные – зафиксированные элементарные сведения о каком-либо факте, взятые вне общего контекста;
информация – упорядоченные и агрегированные данные, рассматриваемые в едином контексте;
знания – осмысленная и проанализированная кем-либо информация.

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

Любое изменение приводит к тому, что часть знаний, ранее доступная одним людям, становится доступной и другим. В целом это мощный фактор, способствующий повышению эффективности работы организации. Но существует ряд моментов, которые могут помешать совместному использованию знаний. «Мы столько можем, сколько знаем. Знание – сила» (Ф. Бэкон). Тот, кто владеет каким-либо знанием, может быть совсем не заинтересован в его передаче другим. Совместному использованию знаний могут помешать организационные или функциональные барьеры между подразделениями, различия в корпоративной культуре, технологические ограничения.

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

Все эти возможные проблемы и риски должны быть обобщены и проанализированы командой проекта в ходе управления преобразованиями. Для каждой группы сотрудников нужно определить:

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

4. Обучение сотрудников.

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

В плане обучения должны содержаться четкие ответы на следующие вопросы: «Кого, чему, как, когда и где обучать?»

Управление обязательствами.

Раздел «Управление обязательствами» соответствует управлению проектами. Главной особенностью реализации подходов проектного управления в методологии AVM является тесная связь с моделью ValueFrame. Это означает, что в ходе управления проектом контролируется не только процесс выполнения отдельных видов работ, но и сам факт достижения заданного бизнес-результата. В ходе «Управления обязательствами» осуществляется согласование планов и координация действий всех участников проекта.