Прийшла недавно мені одна стаття по забугорному списку розсилки. І спонукала мене накидати документ, котрий в якійсь мірі зводить воєдино досвід як мого спілкування з забугорними спецами по OSS/BSS інтеграції, так і власних помилок.
І ось що вийшло.
-----------------
Содержание
1 Введение
2 Опросник, предназначенный для определения бизнес-требований пользователей
2.1 Бизнес-требования
2.2 Технологии и технические требования
2.3 Требования по интеграции
3 Обеспечение гибкости плана проекта
4 Основные приемы оптимального выполнения плана имплементации сетевых сервисов
4.1 Надежная архитектура
4.2 Стандартизированные конфигурации и детализированный проект
4.3 Приобретение и поставка
4.4 Готовность участка внедрения
4.5 Планирование и снабжение
4.6 Управление изменениями
4.7 Предварительный запуск участка
4.8 Тестирование участка
4.9 Передача участка в эксплуатацию
1 Введение
Что это за документ
Настоящий документ является некой аналитической интеграцией идей и мыслей, вызванных изучением:
І ось що вийшло.
-----------------
Содержание
1 Введение
2 Опросник, предназначенный для определения бизнес-требований пользователей
2.1 Бизнес-требования
2.2 Технологии и технические требования
2.3 Требования по интеграции
3 Обеспечение гибкости плана проекта
4 Основные приемы оптимального выполнения плана имплементации сетевых сервисов
4.1 Надежная архитектура
4.2 Стандартизированные конфигурации и детализированный проект
4.3 Приобретение и поставка
4.4 Готовность участка внедрения
4.5 Планирование и снабжение
4.6 Управление изменениями
4.7 Предварительный запуск участка
4.8 Тестирование участка
4.9 Передача участка в эксплуатацию
1 Введение
Что это за документ
Настоящий документ является некой аналитической интеграцией идей и мыслей, вызванных изучением:
- документов ТелеМенеджмент Форума (в основном касающихся структуры NGOSS – TMF GB927, карты бизнес-процессов eTOM – TMF GB921, «Service Delvery Framework» - TMF TR139 и TMF TR141),
- функционала отдельных модулей OSS-систем (в основном «SDP, Service Delivery Platform» by Telcordia),
- ряда открытых публикаций в специализированных Интернет-изданиях,
- идей Telco 2.0 Инициативы (особенно касательно network neutrality)
- и практики проведения консалтинговых работ по проекту внедрения модулей и частей OSS.
Для кого предназначен
Документ может быть полезным как операторам так и предприятиям-собственникам корпоративных сетей, перед которыми стоит задача внедрения или модификации сетевых сервисов для решения высокоуровневых задач бизнеса.
Рассматриваемые вопросы
Трансляция потребностей пользователей в сетевые сервисы отчасти является искусством, отчасти наукой. Лучшие мировые практики в этом вопросе предполагают проведение работ по идентификации нужд пользователей путем составления и заполнения специальных анкет-опросников, предназначенных для определения бизнес-требований, затем трансляции этих бизнес-требований в технические требования и технологические решения (см. рис.1 - структуру NGOSS: Business View (eTOM), System View (SID, Share Information and Data), Implementation View (TNA, Technology Neutral Architecture), Deployment View (TAM, Telecom Application Map)).
После этого составляется план проектных работ для практического воплощения такого последовательного отображения. Самое сложное в данном вопросе, как показала практика – это понимание ключевых шагов выполнения проекта для соблюдения его бюджета и временных рамок. Далее рассмотрим все перечисленные выше вопросы по порядку.
Рисунок 1. Структура NGOSS
2 Опросник, предназначенный для определения бизнес-требований пользователей
Сетевые сервисы могут быть определены различными путями. Их примеры содержат разворачивание на операторской сети сервисов VoIP, Video-over-IP, бизнес-приложений SAP, CRM, Citrix и др., работоспособность которых зависит от функционала собственно самой сети.
В настоящее время большинство предприятий (особенно крупных) в значительной мере зависит от сети и способности сетевых сервисов поддерживать бизнес-приложения этих предприятиий. И как правило существуют различные варианты технологий (или их модификации), позволяющие имплементировать эти сетевые сервисы таким образом, чтобы достигалась оптимальность выполнения бизнес-приложений.
Бизнес-требования выступают являются движущей силой развития технологий (а не наоборот). Поэтому понимание самых важных бизнес-требований клиента и их трансляция в технические требования и технологические решения являются наиболее критичными аспектами в деле успешного внедрения сетевых услуг.
Сбор бизнес-требований – суть довольно интенсивный процесс. Общепринято этот процесс рассматривать с точки зрения трех ключевых областей:
Документ может быть полезным как операторам так и предприятиям-собственникам корпоративных сетей, перед которыми стоит задача внедрения или модификации сетевых сервисов для решения высокоуровневых задач бизнеса.
Рассматриваемые вопросы
Трансляция потребностей пользователей в сетевые сервисы отчасти является искусством, отчасти наукой. Лучшие мировые практики в этом вопросе предполагают проведение работ по идентификации нужд пользователей путем составления и заполнения специальных анкет-опросников, предназначенных для определения бизнес-требований, затем трансляции этих бизнес-требований в технические требования и технологические решения (см. рис.1 - структуру NGOSS: Business View (eTOM), System View (SID, Share Information and Data), Implementation View (TNA, Technology Neutral Architecture), Deployment View (TAM, Telecom Application Map)).
После этого составляется план проектных работ для практического воплощения такого последовательного отображения. Самое сложное в данном вопросе, как показала практика – это понимание ключевых шагов выполнения проекта для соблюдения его бюджета и временных рамок. Далее рассмотрим все перечисленные выше вопросы по порядку.
Рисунок 1. Структура NGOSS
2 Опросник, предназначенный для определения бизнес-требований пользователей
Сетевые сервисы могут быть определены различными путями. Их примеры содержат разворачивание на операторской сети сервисов VoIP, Video-over-IP, бизнес-приложений SAP, CRM, Citrix и др., работоспособность которых зависит от функционала собственно самой сети.
В настоящее время большинство предприятий (особенно крупных) в значительной мере зависит от сети и способности сетевых сервисов поддерживать бизнес-приложения этих предприятиий. И как правило существуют различные варианты технологий (или их модификации), позволяющие имплементировать эти сетевые сервисы таким образом, чтобы достигалась оптимальность выполнения бизнес-приложений.
Бизнес-требования выступают являются движущей силой развития технологий (а не наоборот). Поэтому понимание самых важных бизнес-требований клиента и их трансляция в технические требования и технологические решения являются наиболее критичными аспектами в деле успешного внедрения сетевых услуг.
Сбор бизнес-требований – суть довольно интенсивный процесс. Общепринято этот процесс рассматривать с точки зрения трех ключевых областей:
- Бизнес-требования
- Технологии и технические требования
- Требования по интеграции
2.1 Бизнес-требования
Бизнес-требования фокусируются на четком понимании того, куда пользователь двигается с точки зрения его будущей экспансии на новые рынки, внедрения новых возможностей по сервисам, финансирования и видения развития операционной деятельности. В большинстве случаев, как уже отмечалось выше, все это (то есть принятые бизнес-решения) является определяющим фактором для последующих ИТ-инициатив. А уже ИТ-отделы, или службы отвечают собственно за разворачивание сети, обеспечение ее бесперебойной работы и производительности, поддержку критичных бизнес-приложений. Естественно, что ИТ-отдел во многих случаях для решения каких-либо оперативных вопросов вынужден контактировать с бизнес-единицами, но в общем и целом работа ИТ-отдела является реактивной, по факту (то есть, они безусловно принимают к исполнению решения бизнес-руководства, являясь обеспечивающим подразделением).
Лучшие мировые практики рекомендуют рассмотрение и формализацию бизнес-требований в трехлетней перспективе с целью определения на их основе того какие сетевые сервисы будут необходимы для поддержки бизнеса предприятия.
2.2 Технологии и технические требования
Необходимые технологии и технические требования определяются после бизнес-требований и фактически являются производными от последних.
Технологические требования содержат определения стыков вендорских решений и требований стандартизации. Технические требования представляют собой детализацию проектов решений, предполагающихся к внедрению для поддержки бизнес-требований, которые предсталяются в виде высокоуровневых сетевых приложений. Исходя из вышесказанного технические требования содержат следующие компоненты:
Бизнес-требования фокусируются на четком понимании того, куда пользователь двигается с точки зрения его будущей экспансии на новые рынки, внедрения новых возможностей по сервисам, финансирования и видения развития операционной деятельности. В большинстве случаев, как уже отмечалось выше, все это (то есть принятые бизнес-решения) является определяющим фактором для последующих ИТ-инициатив. А уже ИТ-отделы, или службы отвечают собственно за разворачивание сети, обеспечение ее бесперебойной работы и производительности, поддержку критичных бизнес-приложений. Естественно, что ИТ-отдел во многих случаях для решения каких-либо оперативных вопросов вынужден контактировать с бизнес-единицами, но в общем и целом работа ИТ-отдела является реактивной, по факту (то есть, они безусловно принимают к исполнению решения бизнес-руководства, являясь обеспечивающим подразделением).
Лучшие мировые практики рекомендуют рассмотрение и формализацию бизнес-требований в трехлетней перспективе с целью определения на их основе того какие сетевые сервисы будут необходимы для поддержки бизнеса предприятия.
2.2 Технологии и технические требования
Необходимые технологии и технические требования определяются после бизнес-требований и фактически являются производными от последних.
Технологические требования содержат определения стыков вендорских решений и требований стандартизации. Технические требования представляют собой детализацию проектов решений, предполагающихся к внедрению для поддержки бизнес-требований, которые предсталяются в виде высокоуровневых сетевых приложений. Исходя из вышесказанного технические требования содержат следующие компоненты:
- Архитектурные требования. Данный вид требований обеспечивает входные данные для выбора основных сетевых технологий: LAN, WAN, центры обработки и консолидация данных, выбор между централизованными, либо распределенными ИТ-операциями.
- Требования по полосе пропускания и масштабированию. Данный вид требований определяет кто и где именно (место в сети) будет использовать сервисы высокоуровневых приложений, и какая полоса пропускания для этого требуется. Исходя из этого принимаются решения об архитектуре WAN-сети, решений по удаленному доступу и общем размере сетевой инфраструктуры.
- Требования по интеграции. Эти требования определяют выбор технологических решений таких как, например, функционал вендорских решений и их совместимость с текущей сетевой инфраструктурой.
- Требования по управлению. Данный вид требований определяет как сеть будет управляться с точки зрения сетевых проблем и аварий, конфигурации и производительности.
- Требования по безопасности. Эти требования определяют каким образом будет обеспечиваться безопасность сервисов, предоставляемых приложениями. Данный вид требований является необходимым особенно с точки зрения требований локального законодательства. То есть, они дают ответ на вопросы как осуществляется контроль за ограничением доступа к сети, аутентификацией и авторизацией пользователей, криптованием передаваемых данных и т.п..
2.3 Требования по интеграции
Данный вид требований определяет процесс развертывания, временной график плана работ, задачи и распределение ресурсов, необходимых для реализации проекта по внедрению сетевых сервисов.
Ключевыми вопросами требований по интеграции являются следующие:
Данный вид требований определяет процесс развертывания, временной график плана работ, задачи и распределение ресурсов, необходимых для реализации проекта по внедрению сетевых сервисов.
Ключевыми вопросами требований по интеграции являются следующие:
- Требуется ли заказчиком формальное управление проектом внедрения сетевых сервисов?
- Составлен ли заказчиком четкий перечень всех задач, подлежащих решению для внедрения сетевых сервисов?
- Составлен ли заказчиком временной график внедрения сетевых сервисов?
- Владеет ли заказчик всеми необходимыми внутренними ресурсами для внедрения сетевых сервисов?
- Разработан ли детальный план проекта внедрения сетевых сервисов?
Крайне необходимо перед началом работ иметь ответы на все эти вопросы. Более того, эти ответы должны быть кристально четкие и понятные, потому как они являются залогом правильных решений и действий по имплементации проекта внедрения сетевых сервисов. Добавим, что процесс нахождения ответов на поставленные вопросы может оказаться довольно длительным. Это нормально. Экономить на времени здесь крайне нецелесообразно исходя из цены ошибки на данном этапе.
3 Обеспечение гибкости плана проекта
План проекта представляет собой испытанное и верное средство для достижения успеха в деле имплементации сетевых сервисов и сопутствующей ей сложного процесса интеграции многих составных частей. Для отслеживания статуса работ по проекту существует много инструментариев и средств. В данном документе они не рассматриваются. Вместе этого приводятся общие подходы по созданию плана проекта, основанные на лучших мировых практиках и повышающих вероятность успешного завершения работ по внедрению сетевых сервисов.
По самой своей природе проектные планы во многих случаях являются достаточно негибкими. Они представляют собой запланированную последовательность событий, (могущих происходить либо параллельно, либо последовательно по отношению одно к другому), взаимосвязей между ними и их предшественниками (тоже событиями). И все это «размазано» по всему проектному плану. Хорошим примером типичного проектного плана является организация и разворачивание сети, зависящее от процессов организации тендера, выбора поставщиков, заказа и доставки оборудования. Без решения этих вопросов разворачивание сети невозможно. Но реальность такова, что проект редко продвигается согласно плану. Посему в плане проекта должна быть предусмотрена определенная степень гибкости, предоставляющая возможность маневра и коррекции.
Хороший план проекта начинается с составления перечня всех контактов участников (или групп участников), задействованных в проекте, или имеющих к нему отношение. Типичный проект по внедрению сетевых сервисов, состоящий из работ по инсталляции новых механизмов, или реконфигурации существующих, должен содержать контакты на следующие группы людей:
3 Обеспечение гибкости плана проекта
План проекта представляет собой испытанное и верное средство для достижения успеха в деле имплементации сетевых сервисов и сопутствующей ей сложного процесса интеграции многих составных частей. Для отслеживания статуса работ по проекту существует много инструментариев и средств. В данном документе они не рассматриваются. Вместе этого приводятся общие подходы по созданию плана проекта, основанные на лучших мировых практиках и повышающих вероятность успешного завершения работ по внедрению сетевых сервисов.
По самой своей природе проектные планы во многих случаях являются достаточно негибкими. Они представляют собой запланированную последовательность событий, (могущих происходить либо параллельно, либо последовательно по отношению одно к другому), взаимосвязей между ними и их предшественниками (тоже событиями). И все это «размазано» по всему проектному плану. Хорошим примером типичного проектного плана является организация и разворачивание сети, зависящее от процессов организации тендера, выбора поставщиков, заказа и доставки оборудования. Без решения этих вопросов разворачивание сети невозможно. Но реальность такова, что проект редко продвигается согласно плану. Посему в плане проекта должна быть предусмотрена определенная степень гибкости, предоставляющая возможность маневра и коррекции.
Хороший план проекта начинается с составления перечня всех контактов участников (или групп участников), задействованных в проекте, или имеющих к нему отношение. Типичный проект по внедрению сетевых сервисов, состоящий из работ по инсталляции новых механизмов, или реконфигурации существующих, должен содержать контакты на следующие группы людей:
- Контакты группы по архитектурным и инженерным решениям
- Контакты места проведения работ
- Контакты на группу, обеспечивающую готовность к проведению соответствующих видов работ
- Контакты на группу обеспечения (в т.ч. ресурсами)
- Контакты на группы, отвечающие за отдельные участки проведения работ
- Контакты на группу, отвечающие за интеграцию проектных работ
- Контакты на группу тестирования
- Контакты на группу сетевых операций (типа NOC)
- Контакты на группу, отвечающую за корпоративные коммуникации
- Контакты на группу по управлению проектом
Каждая из этих групп представляет различные сферы деятельности организации, и информация от всех этих групп необходима для создания общего плана проекта. Согласно лучших мировых практик представители от каждой из этих групп должны принимать активное участие в процессе планирования. Проведение общих собраний этих представителей в одной комнате с определением целей, временных графиков каждого из них позволяет всем группам четко знать свои обязанности и зоны ответственности. После этого следует обсудить и определить взаимодействия групп и ограничения, накладываемые характером этих взаимодействий. Все это позволит группам максимально предусмотреть различные неожиданности, возникающие (или могущие возникнуть) в ходе реализации проекта.
Коммуникация между этими группами важна с точки зрения обеспечения гибкости плана проекта. Если все группы действительно понимают свои роли, обязанности, ограничения и взаимозависимости, то может быть составлен план реакции на непредвиденные обстоятельства, который будет учитывать определенную степень гибкости в возможном перемещении проектных вех (milestones) вверх, или вниз в пределах временного графика проекта. Такая гибкость, основанная на планировании непредвиденных обстоятельств, является критическим компонентом для успешного выполнения проекта.
Прекрасным примером этого может выступать план реакции на непредвиденные обстоятельства в проекте миграции к MPLS WAN. В таком проекте существуют сотни тысяч компонентов и их взаимосвязей, потому планирование всех задач, временных графиков и ресурсов является основной его (проекта) проблемой. В большинстве подобных миграционных проектов обязательно возникают различные непредвиденные задержки, в связи с чем совершенно необходимо предусматривать определенную степень гибкости в планировании графика миграции участков сети. Общепринятый подход к решению данной проблемы состоит в категоризации частей проекта на высокорисковые, среднерисковые и низкорисковые. Низкорисковые части вводятся в план проекта с пониманием того, что эти части имеют большую степень свободы в плане продвижения вверх или вниз в пределах временной оси для обеспечения оптимальности порядка выполнения работ в случае задержек. Это обеспечивает высокий уровень гибкости для проекта и минимизирует риск критичных нарушений графика проекта.
Резюмируя, еще раз повторим, что гибкость проектного плана достигается посредством:
Коммуникация между этими группами важна с точки зрения обеспечения гибкости плана проекта. Если все группы действительно понимают свои роли, обязанности, ограничения и взаимозависимости, то может быть составлен план реакции на непредвиденные обстоятельства, который будет учитывать определенную степень гибкости в возможном перемещении проектных вех (milestones) вверх, или вниз в пределах временного графика проекта. Такая гибкость, основанная на планировании непредвиденных обстоятельств, является критическим компонентом для успешного выполнения проекта.
Прекрасным примером этого может выступать план реакции на непредвиденные обстоятельства в проекте миграции к MPLS WAN. В таком проекте существуют сотни тысяч компонентов и их взаимосвязей, потому планирование всех задач, временных графиков и ресурсов является основной его (проекта) проблемой. В большинстве подобных миграционных проектов обязательно возникают различные непредвиденные задержки, в связи с чем совершенно необходимо предусматривать определенную степень гибкости в планировании графика миграции участков сети. Общепринятый подход к решению данной проблемы состоит в категоризации частей проекта на высокорисковые, среднерисковые и низкорисковые. Низкорисковые части вводятся в план проекта с пониманием того, что эти части имеют большую степень свободы в плане продвижения вверх или вниз в пределах временной оси для обеспечения оптимальности порядка выполнения работ в случае задержек. Это обеспечивает высокий уровень гибкости для проекта и минимизирует риск критичных нарушений графика проекта.
Резюмируя, еще раз повторим, что гибкость проектного плана достигается посредством:
- надлежащего планирования,
- высоким уровнем коммуникации между группами
- и хорошо продуманным планом реакции на непредвиденные обстоятельства.
4 Основные приемы оптимального выполнения плана имплементации сетевых сервисов
Оптимальная имплементация сетевых сервисов начинается с надлежащего общего планирования. Независимо от того, насколько полезными (в финансовом плане) будут новые сетевые сервисы, проблемы в их внедрении могут свести на нет всю их выгоду, посеять сомнения в их выгоде, и, более того, могут даже привести к ощутимым финансовым потерям. Внедрение сетевых сервисов как правило требует инсталляции и конфигурации нового оборудования. Без соответствующего планирования это может представлять собой большую опасность как с точки зрения срывов графика внедрения так и с точки зрения перспективы интеграции. Следует за всякую цену избегать временных задержек и неблагоприятного влияния любых действий на функционирующую сеть.
Планирование процесса внедрения должно сосредотачиваться на следующих областях:
Оптимальная имплементация сетевых сервисов начинается с надлежащего общего планирования. Независимо от того, насколько полезными (в финансовом плане) будут новые сетевые сервисы, проблемы в их внедрении могут свести на нет всю их выгоду, посеять сомнения в их выгоде, и, более того, могут даже привести к ощутимым финансовым потерям. Внедрение сетевых сервисов как правило требует инсталляции и конфигурации нового оборудования. Без соответствующего планирования это может представлять собой большую опасность как с точки зрения срывов графика внедрения так и с точки зрения перспективы интеграции. Следует за всякую цену избегать временных задержек и неблагоприятного влияния любых действий на функционирующую сеть.
Планирование процесса внедрения должно сосредотачиваться на следующих областях:
- Надежная (robust) архитектура
- Стандартизированные конфигурации и детализированный проект
- Приобретение и поставка
- Готовность участка внедрения
- Планирование и снабжение
- Управление изменениями
- Запуск участка
- Тестирование участка
- Передача участка в эксплуатацию
Каждая из этих областей подвержена внесению оплошностей и ошибок в общий процесс внедрения проекта, поэтому четкое понимание их ключевых вопросов является крайне важным.
4.1 Надежная архитектура
Надежная (robust) архитектура – это такая архитектура, которая определяет все архитектурные аспекты, включая требуемый функционал, возможности, интеграцию в существующую сеть и наблюдаемость с точки зрения управления. Если новые сетевые сервисы вводятся путем внедрения новой технологии, с которой у организации нет предшествующего опыта работ, крайне рекомендуется, чтобы тестовая лаборатория провела Proof-of-Concept (PoC), или испытать технологию на пилотном проекте еще до развертывания реального проекта.
4.2 Стандартизированные конфигурации и детализированный проект
Если возможно, для элементов сети, предоставляющих сетевые услуги, должны быть созданы шаблоны стандартных конфигураций. Много усилий по инсталляции идут прахом именно из-за несогласованностей в конфигурационных механизмах во время развертывания проекта и трудностей в поиске неисправностей в условиях нестандартного окружения.
Должен быть разработан детализированный проект, который подчеркивает специфические особенности конфигурации для каждого участка внедрения. Это должно быть сделано еще до развертывания проекта так, чтобы определенная для оборудования или определенная для участка информация могла быть привязана непосредственно к деталям проекта, касающихся каждого отдельного участка, включая отображение портов (port mapping), имена интерфейсов, имена хостов, IP-адресация, VLAN-адресация, номерные планы и другие многочисленные параметры конфигурации, специфичные для участка. Во всех случаях наличие детальной информации о специфических деталях, характерных для конфигурации отдельных участков и стандартных шаблонов конфигурации для иных участков сильно сокращает общее количество ошибок во время развертывания проекта.
4.3 Приобретение и поставка
Процесс приобретения и поставки (procurement process) должен предусматривать непредвиденные обстоятельства для всех нижеперечисленных (и подобных им) причин и всех использующихся каналов коммуникации:
4.1 Надежная архитектура
Надежная (robust) архитектура – это такая архитектура, которая определяет все архитектурные аспекты, включая требуемый функционал, возможности, интеграцию в существующую сеть и наблюдаемость с точки зрения управления. Если новые сетевые сервисы вводятся путем внедрения новой технологии, с которой у организации нет предшествующего опыта работ, крайне рекомендуется, чтобы тестовая лаборатория провела Proof-of-Concept (PoC), или испытать технологию на пилотном проекте еще до развертывания реального проекта.
4.2 Стандартизированные конфигурации и детализированный проект
Если возможно, для элементов сети, предоставляющих сетевые услуги, должны быть созданы шаблоны стандартных конфигураций. Много усилий по инсталляции идут прахом именно из-за несогласованностей в конфигурационных механизмах во время развертывания проекта и трудностей в поиске неисправностей в условиях нестандартного окружения.
Должен быть разработан детализированный проект, который подчеркивает специфические особенности конфигурации для каждого участка внедрения. Это должно быть сделано еще до развертывания проекта так, чтобы определенная для оборудования или определенная для участка информация могла быть привязана непосредственно к деталям проекта, касающихся каждого отдельного участка, включая отображение портов (port mapping), имена интерфейсов, имена хостов, IP-адресация, VLAN-адресация, номерные планы и другие многочисленные параметры конфигурации, специфичные для участка. Во всех случаях наличие детальной информации о специфических деталях, характерных для конфигурации отдельных участков и стандартных шаблонов конфигурации для иных участков сильно сокращает общее количество ошибок во время развертывания проекта.
4.3 Приобретение и поставка
Процесс приобретения и поставки (procurement process) должен предусматривать непредвиденные обстоятельства для всех нижеперечисленных (и подобных им) причин и всех использующихся каналов коммуникации:
- Невозможность инсталляции по причине неприбытия в срок необходимого оборудования
- Получение не того оборудования, которое было заказано
- Оборудование, испорченное в процессе доставки
Это делается для того, чтобы предусмотреть и немедленно учесть все задержки еще до собственно этапа внедрения проекта.
4.4 Готовность участка внедрения
Независимо от того, насколько качественно была определена и разработана архитектура и насколько скрупулезно прописаны детали конфигураций, но если участок сети, на котором должны быть произведены изменения, не готов к работам, то весь проект не способен даже сдвинуться с места. Готовность участка к произведению изменений должна как минимум рассматриваться с точки зрения готовности свободного места, электропитания и требований HVAC (Heating, Ventilating and Air Conditioning, - иногда говорят «климат контроль»), наличие и доступности портов и разграничения всех возможных расширений. Нет ничего более раздражающего, чем невозможность произведения работ только потому, что никто не удосужился банально посмотреть есть ли свободное место в серверной для размеения нового оборудования.
4.5 Планирование и снабжение
Контроль за тем, что правильные ресурсы, установленные в правильное место, в нужное время решают правильные (соответственные) задачи, является необходимым для любого успешного проекта внедрения. Внедрение зависит от ресурсов и в отрыве от них (само по себе) не происходит. Ненадлежащее (плохое) планирование в этой области практически однозачно приводит к неуспеху внедренческого проекта.
4.6 Управление изменениями
Большинство организаций требует наличие хоть какой-нибудь разновидности процесса управления изменениями, чтобы рассмотреть, спланировать и отрапортовать об изменениях в пределах инфраструктурного окружения. Управление изменениями может быть довольно интенсивным процессом и в некоторых случаях ограниченным определенными временными рамками. Однако игнорирование данного процесса может привести к катастрофическим последствиям в деле внедрения общего проекта.
4.7 Предварительный запуск участка
Для предварительного запуска участка требуется, собственно, само наличие ресурсов для инсталляции и конфигурации элементов сети, предоставляющих новые сетевые услуги. Наличие хорошо задокументироанного инсталляционного и конфигурационного скрипта (списка задач) является существенным для управления требуемыми ресурсами через их инсталляцию в предопределенный способ. Обратная связь от различных усовершенствований и нюансов, изученных с помощью предварительного запуска, обеспечивает механизм определения оптимальной последовательности задач.
4.8 Тестирование участка
Тестирование участка производимых работ чаще всего рассматривается как часть инсталляционных работ. Но кроме тестирования функциональных возможностей сетинеобходимо также проверить сервисы, обеспечиваемые приложениями. Наличие типичного пользовательского автоматизированного рабочего места, на котором выполняются обычные ежедневные задачи, способно обеспечить необходимый уровень тестирования и убедить тест-инженеров и представителей заказчика в том, что модернизированная сеть работает соответственно запланированным ожиданиям.
4.9 Передача участка в эксплуатацию
Для передачи модернизированной сети операционным подразделениям должен быть разработан стандартизированный процесс. Это позволяет в течение одного-двух дней собрать (и отреагировать на) замечания не только от группы по внедрению, но и от операционных подразделений, которым и предстоит эксплуатировать сеть дальше. Также в рамках процесса передачи необходимо предусмотреть обучение операционных подразделений основам и навыкам практической работы с внедряемыми технологиями еще до их развертывания.
В завершение отметим, что все вышерассмотренные вопросы могут сильно воздействовать на успех общего проекта по развертыванию новых сетевых сервисов и замыкаются они опять же на вопрос надлежащего планирования и неукоснительного выполнения разработанного плана.
4.4 Готовность участка внедрения
Независимо от того, насколько качественно была определена и разработана архитектура и насколько скрупулезно прописаны детали конфигураций, но если участок сети, на котором должны быть произведены изменения, не готов к работам, то весь проект не способен даже сдвинуться с места. Готовность участка к произведению изменений должна как минимум рассматриваться с точки зрения готовности свободного места, электропитания и требований HVAC (Heating, Ventilating and Air Conditioning, - иногда говорят «климат контроль»), наличие и доступности портов и разграничения всех возможных расширений. Нет ничего более раздражающего, чем невозможность произведения работ только потому, что никто не удосужился банально посмотреть есть ли свободное место в серверной для размеения нового оборудования.
4.5 Планирование и снабжение
Контроль за тем, что правильные ресурсы, установленные в правильное место, в нужное время решают правильные (соответственные) задачи, является необходимым для любого успешного проекта внедрения. Внедрение зависит от ресурсов и в отрыве от них (само по себе) не происходит. Ненадлежащее (плохое) планирование в этой области практически однозачно приводит к неуспеху внедренческого проекта.
4.6 Управление изменениями
Большинство организаций требует наличие хоть какой-нибудь разновидности процесса управления изменениями, чтобы рассмотреть, спланировать и отрапортовать об изменениях в пределах инфраструктурного окружения. Управление изменениями может быть довольно интенсивным процессом и в некоторых случаях ограниченным определенными временными рамками. Однако игнорирование данного процесса может привести к катастрофическим последствиям в деле внедрения общего проекта.
4.7 Предварительный запуск участка
Для предварительного запуска участка требуется, собственно, само наличие ресурсов для инсталляции и конфигурации элементов сети, предоставляющих новые сетевые услуги. Наличие хорошо задокументироанного инсталляционного и конфигурационного скрипта (списка задач) является существенным для управления требуемыми ресурсами через их инсталляцию в предопределенный способ. Обратная связь от различных усовершенствований и нюансов, изученных с помощью предварительного запуска, обеспечивает механизм определения оптимальной последовательности задач.
4.8 Тестирование участка
Тестирование участка производимых работ чаще всего рассматривается как часть инсталляционных работ. Но кроме тестирования функциональных возможностей сетинеобходимо также проверить сервисы, обеспечиваемые приложениями. Наличие типичного пользовательского автоматизированного рабочего места, на котором выполняются обычные ежедневные задачи, способно обеспечить необходимый уровень тестирования и убедить тест-инженеров и представителей заказчика в том, что модернизированная сеть работает соответственно запланированным ожиданиям.
4.9 Передача участка в эксплуатацию
Для передачи модернизированной сети операционным подразделениям должен быть разработан стандартизированный процесс. Это позволяет в течение одного-двух дней собрать (и отреагировать на) замечания не только от группы по внедрению, но и от операционных подразделений, которым и предстоит эксплуатировать сеть дальше. Также в рамках процесса передачи необходимо предусмотреть обучение операционных подразделений основам и навыкам практической работы с внедряемыми технологиями еще до их развертывания.
В завершение отметим, что все вышерассмотренные вопросы могут сильно воздействовать на успех общего проекта по развертыванию новых сетевых сервисов и замыкаются они опять же на вопрос надлежащего планирования и неукоснительного выполнения разработанного плана.
Немає коментарів:
Дописати коментар