Otvety uchastnikov marafona kejs 4x

Ответы участников марафона на второй тур, кейс 4
Участники перечислены в алфавитном порядке, авторская стилистика, пунктуация и проч.
сохранены.
Айдиев Расул
1. Проведение тестирование, как отдельных участков системы, так и комплексное, участие в
тестировании медперсонала, который будет пользоваться системой, прогонять типовые бизнес
процессы.
2. Оставить наплаву старую систему в качестве дублирующей до момента полной отладки новой
системы, с обеспечением синхронизации данных между этими системами (двунаправленный
обмен данными). Тем более лишнее оборудование для этого есть.
3. Мотивировал подрядчика - будучи ИТ директором я бы изначально сильно учел финансовые
последствия просрочки при пуско-наладке новой информационной системы со стороны
подрядчика, прописал бы в договоре
4. Не создавал бы велосипед, а пользовался бы готовым. Отраслевым решением crm к примеру
terrasoft http://www.terrasoft.ru/industries/medicine и экспортировал все данные в неё.
5. Предложил бы модульную систему, в который каждый модуль мог работать самостоятельно и
не зависел вообще или не сильно от других модулей. То есть при выходе из строя одного модуля
остальные оставались работоспособны.
Григоров Кирилл
Прежде чем начинать что-то менять, давайте сначала определимся с текущей ситуацией. Что мы
имеем сейчас?
1. 2 одновременных крупных изменения в информационной системе предприятия.
2. Нестабильная работа новой финансовой ИС.
3. Проблема с архитектурой новой ИС
4. Отсутствие адекватных приёмо-сдаточных испытаний.
Из кейса не совсем понятно – систему запускают сразу на новом железе или установка нового
оборудования идёт параллельно? Судя по тому, что задач стоит 2 (заменить и мигрировать),
предположу, что внедрение идёт на старую аппаратную платформу, а новая разворачивается
параллельно. Из этого и будем исходить.
Итак, первым делом надо разделить программистов и железячников. Если, как описано в кейсе,
они сидят рядом (…программисты и аналитики подрядчика будут находиться в помещении
ЦОДа заказчика….), то одни мешают другим, поэтому переводим одних в другое помещение. Это
позволит каждой рабочей группе сформировать своё окружение, своё информационное поле,
которое позволит не отвлекаться на другие задачи.
Судя по тому, что система работает нестабильно и её перезапуск занимает от 6 до 8 часов (!!!!),
предположу, что есть проблемы с начальной архитектурой приложения. Тут два варианта:
1. Архитектуры нет
2. Архитектура есть, но она плохая.
На этом этапе, как мне кажется, проект по внедрению нужно поставить на паузу, чтобы
разобраться с глобальными вещами, в том числе и с архитектурой приложения. По условиям кейса
нигде не сказано, что старое приложение уже отключено, поэтому подразумеваем, что
пользователи работают в старой ИС, пока новая ИС внедряется. Значит, можно придержать коней
и всё-таки решить стратегические вопросы, которые относятся к переходу на новую систему.
Иначе в будущем всё может быть ещё хуже. Что сюда может входить?
1. Описание новой системы, взаимодействие модулей друг с другом.
2. Архитектура системы, её модулей, описание БП и т.п.
3. Оценка рисков.
4. Формализация процедуры приёмо-сдаточных испытаний.
Скорее всего, какая-нибудь информация уже есть, ведь не началось же внедрение на пустом месте.
В этом случае нужно пересмотреть и скорректировать эти данные, основываясь на тех ошибках,
которые вылезли в процессе внедрения.
Кроме этого нужно привлечь функциональные подразделения и с их помощью разработать
критерии тестирования новой системы для дальнейших испытаний при приёмке. Это поможет
поставить более чёткую задачу подрядчику и упростит контроль конечного результата.
Параллельно у нас идёт процесс построения новой ИТ-инфраструктуры – спокойно и без суеты
инсталлируем оборудование, устанавливаем системное ПО, тестируем работу аппаратных
компонентов и т.п. Одним словом, готовим платформу для будущего переезда внедрённой ИС.
Таким образом, нам нужно:
1. Разделить программистов и аппаратников друг от друга.
2. Скорректировать стратегические документы проекта по внедрению.
3. Формализовать процессы, при помощи которых происходит тестирование и приёмка
системы (для упрощения контроля подрядчика)
4. Параллельно готовить новую аппаратную платформу, не отказываясь от старой системы.
5. После внедрения новой ИС начать переводить её на новую аппаратную платформу. Тем
самым мы будем производить по 1 глобальному изменению в системе (сначала софт,
потом – железо) и это позволит нам точно идентифицировать возникающие ошибки в
работе ИС.
Денисов Михаил
1. Пересмотреть сроки проектов «1. замена приложения на новое» и «2. миграция с
платформы на новое». Проект №2 отложить до завершения проекта №1. (так как
платформа работает стабильно, то нет необходимости одновременно вести два
взаимосвязанных проекта). Вернуть приложение на прежнюю платформу
Это решение позволит снизить количество ошибок аппаратного обеспечения и сделать
процесс внедрения ПО более контролируемым.
2. Необходимо сделать ретроспективу проекта:
a. Проанализировать выявленные недостатки/проблемы и отразить их причины
b. По итогам анализа причин проблем принять решение о том, стоит менять
подрядчика или нет.
c. Заново выполнить проектирование, включающее все фазы проекта. При
проектировании спланировать внедрение таким образом, чтобы минимально
влиять на работу людей (запланировать тестовую площадку, контрольные
примеры/кейсы, варианты отката к предыдущей версии в случае неудачи)
d. Организовать систематические совещания по ходу проекта
3. Определить среди пользователей заказчика ответственных за внедрение каждого участка.
Составить список требований и критериев приемки результата. Разработать мотивацию для
пользователей заказчика, обеспечивающих приемку работ (мотивация должна быть нацелена
на сроки и качество принимаемых работ)
Зубков Антон
Прежде всего провести совещание всех вовлеченных сторон для выявления корневых причин
проблемы. В зависимости от этого возможны следующие варианты:
Прежде всего сфокусировать проект на внедрении нового приложения. Отложить задачу
миграции на новую платформу, если это оправдано финансово и т.п.
Очень может быть необходимо заменить руководителя проекта. Положительный эффект
может оказаться большим, чем связанные с этим риски. Найдя замену среди нынешних
участников проекта, риски можно снизить
Пересмотреть процесс управления проектом – есть ли Управляющий Комитет, нужно ли
его усилить и заставить работать с рисками.
Если у подрядчика не хватает ресурсов – принять соответствующие меры
Аналогично, если проблема с нехваткой собственных ресурсов в проекте или их
компетенцией
Если причиной проблем определена нехватка компетенции, принять соответствующие
меры.
Возможно выявленные проблемы будут более стратегического уровня:
Проект может быть дешевле отменить, чем доводить до конца и терпеть убытки из-за
некачественного внедрения
Возможно проблемы внедрения связаны с неготовностью общей инфраструктуры. Сначала
необходимо ее централизовать, унифицировать и т.п.
Иванов Эдуард
Дано: Крупная компания по предоставлению медицинских услуг; Разношерстные профильные
подразделения; Разнородная ИТинфраструктура; Многочисленные требования по обеспечению
работы компании; Финансовая медсистема собственной разработки; Идет разработка и внедрение
новой финансовой системы; Разработку ведет подрядчик; Новая система выходит из строя два
раза в неделю; Средний срок восстановления системы 7 часов: Отсутствует документация
приемосдаточных испытаний;
Цель: нормализовать проект по внедрению новой системы
Решение:
Скорей всего одна из главных причин выхода проекта из под контроля: формальный подход к
тестированию. В этом случае, как правило, при возникновении аварий и ошибок устраняются
следствия но не выявляются причины. А поскольку нет планомерной работы над причинами, они
накапливаются и возникает эффект лавины, что мы и наблюдаем в данном проекте: регулярно
происходят аварии и требуются значительные ресурсы для их устранения. И, судя по описанию,
устраняются опять таки следствия, а причины никто не ищет.
Надо создать полноценную группу тестирования, которая будет выполнять полный комплекс
работ по тестированию ПО: функциональное тестирование, тестирование взаимодействия,
тестирование безопасности, регрессионное тестирование, нагрузочное тестирование, тестирование
совместимости. В дополнение к тестированию необходимо выделить отдельный процесс по
управлению проблемами.
Другая причина разнородная ИТинфраструктура. Необходимо разработать ИТстандарты и
запустить процесс по приведению ИТ к этим стандартам.
Кожевников Александр
Действия:
1. Ситуация не самая плохая имеем
работающую систему на старом железе и новую систему на новом железе. Контуры разнесены и
можно нормально заниматься тестированием не сильно боясь за промышленный контур.
2. Выделение рабочих групп, состоящих из IT специалистов, менеджера проекта, ответственного
от бизнеса, сотрудников от двух подрядчиков. Рабочие группы делятся по функционалу системы в
разрезе бизнес подразделений. Несколько бизнес подразделений не участвуют в одной группе. Оба
подрядчика нужны для более оперативного определения причины дефекта и прямого
взаимодействия под контролем заказчика. Без очного взаимодействия они смогут долго
перекидывать сбои друг на друга.
3. Разработка и согласование ПМИ для каждой группы.
4. Ведение журнала тестирования и исправления ошибок для каждой группы. В идеале, единая
система багтрекинга под контролем заказчика с доступами для подрядчиков. Это даст контроль
сроков, единая точка входа для всех участников. Если системы нет, то сойдет Excel.
5. Еженедельный сбор проектной группы с контролем сроков, выделением критичных проблем и
обязательным принятием решений, назначение ответственных по каждому решению.
6. Планирование поэтапного ввода функционала в промышленную эксплуатацию. Мы имеем два
контура, ничего этому не мешает, кроме наличия места в серверных. Но временно эта проблема
может быть решена.
7. Анализ идеи отпустить сотрудников подрядчика на удаленку по завершении внедрения. Это
может дать экономию. Может дать прирост качества, но это сильно зависит от подрядчика.
Главный риск в том, что данные медицинской системы (даже счет за лечение с указанием состава
лекарств и процедур) могут быть классифицированы как ИСПДН 1ого класса, а создать
удаленный доступ к такой системе задача не тривиальная. Можно получить неприятные
последствия проверки компетентных органов. Абсолютное большинство банков никогда не дает
подрядчикам внешний доступ, хотя, как минимум часть информационных систем банков
попадают только под 2ой класс защиты.
Козлов Илья
1. Обеспечить
качественную
стандартизованную
процедуру
тестирования
новых
подключаемых модулей, а также внесения изменений в существующие. Для каждого
модуля/функции должен существовать набор тестов и система их автоматического
запуска. Все изменения должны сначала производится на тестовом окружении, и только
после получения положительных результатов тестирования переносится на рабочее
окружение. Перед каждым изменением/обновлением обязательно должен составляться
план «отката» к
предыдущему состоянию системы (в простейшем случае
её
восстановление из резервной копии).
2. Обеспечить резервирование по оборудованию или вычислительным мощностям (в случае
использования виртуализации) для быстрого восстановления после сбоя. При наличии
технической возможности развернуть отказоустойчивый кластер.
3. Начать использовать любой удобный баг-трекер. Если сотрудники лояльны
и
квалифицированы начать использование AGILE подходов методик, например SCRUM.
Колонский Евгений
Рискованно одновременно менять и приложение, и платформу. Если возможно, эти проекты
хорошо бы разделить по времени, выполнять не одновременно.
При этом возможны различные тактики, выбор зависит от баланса между целями, бюджетом,
сроками и внешними обстоятельствами (например, неясно, может ли новое приложение работать
на старой платформе).
Управленческие решения, которые надо принять:
1) разделить по времени проекты по внедрению новой платформы и внедрению нового
приложения. Один из них придется приостановить. По всей видимости, с точки зрения
производства важнее раньше ввести новое приложение, если старая платформа работает стабильно
и к ней нет претензий.
2) Новая система передается в эксплуатацию частями и дважды в неделю (!) останавливается изза негодного качества результатов на 6-8 часов. Для бизнес-критичной системы это недопустимо.
Дальше – больше: вдобавок к переданному в эксплуатацию некачественному продукту в спешном
порядке круглосуточно с колес проектируются и кодируются новые модули такого же низкого
качества. Необходимо пересмотреть тактику реализации проекта и управления проектом и
сфокусироваться на качестве результатов, доступности и масштабируемости. Необходимо оценить
целесообразность продолжения работы с этим подрядчиком. Возможно, придется принять
решение о рестарте проекта.
Кошманенко Ярослав
Ошибка 1 - При покупке разнородных компаний они не были приведены к единым аппаратно техническим требованиям.
Ошибка 2 - Отсутствие единого корпоративного стандарта по ИТ, отсюда проблемы в процессе
внедрения, ведения документации и т.п.
Ошибка 3 - "проектирование приложения решили поручить региональному подрядчику".
Менеджер проекта должен был входить в компанию Заказчика (Например, технический или ИТдиректор)
Алгоритм действий ИТ директора по исправлению ситуации:
- Выгнать подрядчиков по внедрению приложения
- Согласовать с Техническим директором (ТД) порядок и этапность внедрения нового
оборудования
- Разработать новый проект по внедрению системы и модернизации ПО
- Рассмотреть возможности интеграции приобретаемого оборудования и ПО с точки зрения
формирования финансовой отчетности
- Написать ТЗ с указанием входных данных от новой системы и требованиями собственника и
законодательства по формированию выходной отчетности
- После проведения тендера нанять в проект новую организацию - подрядчика
- Требовать от подрядчиков строгого соблюдения плана-графика по проекту и техническую
документацию по внедрению на выходе
- Обучить персонал по работе с новой системой
- Запуск в тестовую, а далее в опытную эксплуатацию нового оборудования и системы учета.
Кудинов Михаил
В данной ситуации налицо нехватка тестирования системы. Чтобы исправить сложившуюся
ситуацию, необходимо усилить контроль качества.
1. Внедрить своих разработчиков к подрядчику и наладить совместную работу и взаимодействие,
учитывая при этом существующие знания и навыки ИТ персонала.
2. Далее необходимо разработать методики проверки, например проводить тестирование на
обычных людях или создать группу для оценки качества, которая будет вести всю документацию
для каждого из обслуживаемых участков (медподразделений).
Кулешов Михаил
1 - "синхронизировать" оба изменения. Старое приложение продолжает работать на старой
платформе до ввода новой, а новое разрабатывается и тестируется на новой.
2 - проработать четкий алгоритм переноса данных со старого приложения на новое.
3 - разработать "тестировочный лист" - инструкцию по проведению тестирования новой системы
для конечных пользователей
4 - на основании "тестировочного листа" - определить "момент перехода" - допустимое количество
ошибок, сбоев, времени восстановления и т.п. - при которых новая система может считаться
отлаженной и готовой к запуску в пром. эксплуатацию
5 - определить предварительный график ввода системы в строй во всех подразделениях:
а) Обеспечение на конечных станциях доступа к новой системе;
б) Перенос данных и предварительное тестирование во всех подразделениях*;
в) Сбор информации и передача аналитикам разработчика;
г) Исправление ошибок и замечаний
д) Пункты "б,в,г" - повторяем пока не выполнен п.4
е) Перенос данных, ввод новой системы, отключение старой.
* При сильно разветвленной сети, возможно тестирование на ключевых (реперных) точках
Лепский Игорь
Вообще ситуация выглядит довольно-таки рабочей и особо критичных проблем в ней не видно.
Давайте разберемся.
1. Существует самописная финансовая система стабильно функционирующая на старом
мейнфрейме. Судя по всему, централизованная. Т.е. у бизнеса пока особых проблем нет. Разве что
система подтормаживает, не справляясь с объемами в пиковых нагрузках.
2. Нанятый подрядчик проектирует новое приложение под новую же платформу, приобретенную с
помощью нового технического директора. Судя по упоминанию общего корпоративного
хранилища, новое приложение тоже будет централизованным.
3. По каким-то неизвестным причинам новая разработка нормально функционировать не желает.
Т.е. разработчик со своими обязанностями не совсем справляется. Трудно предположить, что ИТ
директор нанял подрядчика совершенно не имеющего опыта разработки ПО и управления
проектами по этой тематике. Логично предположить, что разработкой все-таки управляет РП от
исполнителя, знающий процессы планирования и управления процессом по разработке ПО. Какой
смысл ИТ директору пытаться заменить профессионала? РП просто обязан обеспечить весь цикл
разработки от проектирования и кодирования до тестирования, документирования и управления
выпуском.
4. Если проблемы запуска системы в оборудовании, на это есть специалисты вендора, которые,
судя по описанию, в настройке принимают самое активное участие.
5. В такой ситуации ИТ директору остается только собрать рабочее совещание с участием
разработчика и вендора, выяснить на чьей стороне причины сбоев и совместно составить
подробный план-график их устранения. Далее остается только контролировать руководителей
проектов от исполнителей.
6.Максимум, где могут возникнуть проблемы у заказчика, требующие самостоятельного решения,
это интеграция новой платформы в существующую инфраструктуру, если таковая задача
разработчика и поставщикам не ставилась на этапе заключения договоров.
Летуновский Александр
Здесь, как и в предыдущем кейсе, имеет место одновременная реализация двух взаимосвязанных
инфраструктурных проектов, что порождает большое количество отказов и увеличивает время
реализации. Для нормализации ситуации на мой взгляд необходимо сделать следующее:
1. Приостановить работы по приемке нового приложения.
2. Основные усилия направить на реализацию новой аппаратной платформы, полностью ее
подготовить, проверить и сдать в эксплуатацию.
3. Протестировать работу приложения на стабильно работающей аппаратной платформе. При
необходимости доработать ее, провести полноценные ПСИ.
Никифоров Алексей
Бурно растущие предприятия - это, возможно, самое плохое, что может случиться с отделом ИТ. И
вообще для предприятий бурный рост, как не парадоксально, не всегда хорош. Слишком велик
риск резко снизить планку и потерять клиентов вообще.
По кейсу предложения такие.
1. Так как предприятие бурно растет, то не нужно покупать инновационное оборудование, а нужно
арендовать мощности. Это позволит легко масштабировать мощности как вверх, так и вниз без
существенных затрат.
2. По поводу внедрения нового ПО. К сожалению, я не вижу другой схемы, как параллельно
работать некоторое время сразу в двух системах и, только когда будет достигнута некая
стабильность, отказаться от старой и начать работать только в новой. Да, персонал будет
недоволен (работы по двойному вводу), но о мотивировании сотрудников пусть думает отдел
кадров.
3. По поводу пункта: "Приемо-сдаточные испытания формально проводились при сдаче в
эксплуатацию каждого участка у заказчика, однако их результаты не были задокументированы и
выверены с точки зрения реальных результатов для каждого из обслуживаемых участков
(медподразделений). ".
Нам, безусловно, потребуется обучение работе в новой системе. Причем обучением, скорее всего,
будут заниматься представители разработчика софта. Пусть эти представители объедут все наши
медподразделения, в каждом проведут обучение, выявят свои недоработки, исправят их и, получив
подпись на акте приема-передачи от главы медподразделения, получат тот или иной кусочек
оплаты по проекту.
С момента подписания акта, отдел ИТ уже перекладывает ответственность на главу
медподразделения : "Если у тебя не работает, зачем подписывал".
4. Если новый софт очень тяжелый, то, возможно стоит подумать о поэтапном внедрении. Есть два
способа.
Первый способ: часть операций (к примеру, банк-касса) мы делаем в новой программе и оттуда
все временно мигрирует в старую, а остальные операции в старой программе. Потом к условному
"банку-кассе" добавляем ОС, материалы, зарплату и так далее. Да, выйдет дороже, но зато на
персонал нет очень высокой нагрузки - всё делается постепенно с оттачиванием мельчайших
деталей и переходим к новым участкам только, когда к реализованным нет вопросов.
Второй вариант - мы не пытаемся перевести сразу все медподразделения. Тренируемся на одном.
Когда в одном подразделении добиваемся успеха, то с накопленным опытом едем в другое и
переводим их на новый софт.
Всё и сразу, в реальной жизни, не бывает.
Погорелов Виталий
План действий для ИТ-директора
1.
Прежде всего необходимо признать задержку и невозможность запуска системы в
промышленную эксплуатацию в изначальные сроки. Обсудить новый план и сроки с бизнесом.
2.
Пока новое аппаратное и программное обеспечение не будет показывать стабильную работу
в режиме опытной эксплуатации не передавать промышленную нагрузку со старой на новую
систему.
3.
Провести ревизию всех функциональных, технических и ИБ-требований, и принимать
систему строго по этим требованиям. Документируя все несоответствия.
Пушкарев Алексей
Во-первых необходимо организовать регистрацию возникающих ошибок, способах их
диагностики и их устранения. На основе данной информации необходимо формировать базу
знаний. Это позволит в случае повторения ошибок устранять их в более короткие сроки, на основе
информации имеющейся в базе знаний. Параллельно с этим вести работу по выявлению причин
возникновения ошибок и способах их исправления, как только причины возникновения ошибок
будут устранены, их количество будет сокращаться.
Во-вторых необходимо провести новое тестирование сданных в эксплуатацию участков. С целью
выявления ошибок, отклонений от требований и потенциальных проблем будущего приложения и
платформы. Методику тестирования и его результаты необходимо тщательно задокументировать
и провести анализ выявленных проблем. Включить в план работы по их исправлению. Так же
необходимо будет поступать и с вновь добавляемыми модулями. Возможно так же регламентация
процедуры сдачи в эксплуатацию очередного участка, с целью определения набора формальных
требований к выполнению данной процедуры. Так же регламентация процедуры сдачи в
эксплуатацию поможет сократить время приемо-сдаточных работ, за счет тщательно
прописанного алгоритма действий
В-третьих необходимо нормализовать рабочий день сотрудников, как свой организации так и
подрядчика. Так как переработки неизбежно ведут к снижению качества выполняемых работ, и в
итоге еще большее время требуется на их исправление.
В-четвертых возможно имеет смысл приостановка выкатывания новых модулей, пока не будет
достигнута стабильность в функционировании нового оборудования. Это облегчит диагностику
ошибок, и как следствие общее время на разработку и развертывание новой системы.
Ровенный Сергей
ИТ-подразделения и медподразделения компании ожидают жаркие денечки (подрядчиков – тож):
1. Инсталлировать новое «железо». Исполнитель: ИТ-подразделение + подрядчик.
2. Заставить его стабильно работать со старым приложением. Исполнитель: ИТподразделение + подрядчик.
3. Подготовка и перенос данных из старого приложения в новое. Исполнитель: ИТподразделение.
4. Тестирование нового приложения на новом «железе» с данными из старого приложения.
Исполнитель: ИТ-подразделение.
5. Обучение экспертов медподразделений работе в новом приложении. Исполнитель: ИТподразделение.
6. Тестирование и опытная эксплуатация нового приложения на новом «железе».
Используются данные из старого приложения и данные, отраженные в новом приложении.
Исполнитель: Эксперты медподразделений + ИТ-подразделение. Старое приложение
продолжает работать по-старому.
7. Обучение остальных сотрудников медподразделений работе в новом приложении.
Исполнитель: эксперты медподразделений, ИТ-подразделение «на подхвате».
8. Актуализация данных (см. п.3).
9. Ведение учета в двух приложениях параллельно, в течение, как минимум, 1 месяца.
Исполнитель: медподразделения, ИТ-подразделение «на подхвате».
10. Анализ работы двух приложений при параллельной работе. Принятие решения о
промышленной эксплуатации нового приложения. Исполнители: ИТ-подразделение,
эксперты медподразделений.
11. Промышленная эксплуатация.
12. Хорошо было бы начать промышленную эксплуатацию нового приложения с начала года.
И, соответственно, п.9 выполнить в декабре.
Сейко Игорь
Не до конца понятен мне этот кейс. … Пишу как должно быть, т.к. тот бардак который я
обнаружил исправлению не подлежит…Впрочем, может, я чего не понял…
Процесс текущего функционирования и процесс развития должны быть четко разделены с самого
начала. (Из кейса это не понятно)
В связи с тем, что принято решение «мигрировать со старой стабильно работающей платформы на
новую» я бы предложил вне зависимости от стадии выполненных работ, следующие
рекомендации:
1. старую ИТ инфраструктуру не менять и оставить в существующем виде для обеспечения
стабильного текущего функционирования.
2. создать участок параллельной ИТ инфраструктуры на основе оборудования новой платформы, и
при необходимости обеспечить шлюз между ними;
3. совместно с вендором наладить, оттестировать и запустить в тестовую эксплуатацию этот
участок, используя в качестве экспериментальных, вновь созданные тестовые
автоматизированные рабочие места (АРМ);
4. процесс разработки, отладки и тестирования нового приложения перенести на новый участок,
даже если он уже запущен на оборудовании старой ИТ инфраструктуры;
5. продолжить процесс разработки, отладки и тестирования нового приложения на новом участке
ИТ инфраструктуры, корректно проводя приемо-сдаточные испытания с участием комиссии
компетентных специалистов (ИТ-эшники, бухгалтера, медики) и «неформально» подписывая все
необходимые акты, только после полной проверки работы каждой функции или пакета функций с
тестовых АРМ.
6. после отработки всего функционала нового приложения на тестовом участке ИТ
инфраструктуры, осуществить разовую конвертацию, перенос и загрузку (или шлюзовое
переключение, если хранилища ЦОД остались прежними) актуальных данных со старой
платформы на новую.
7. Осуществить доступ, переключить и настроить все имеющиеся АРМ на новую платформу и
осуществить окончательный административный и программный тюнинг всех АРМ. Конечно же, п.
6 и 7 сделать в нерабочее время (лучше во время продолжительных праздников).
8. Подписать окончательные Акты сдачи-приёмки, оплатить оставшиеся суммы и поставить
систему на удалённое сопровождение региональным подрядчиком.
9. Через год осуществить окончательную утилизацию старого оборудования и ПО. Внимательно
отнестись к утилизации персональных данных на старом оборудовании. Приказом создать
комиссию, составить и подписать соответствующие акты уничтожения ПД.
Серебров Александр
1)
Разобраться с инновационностью, что то чересчур ее много, как бы не скрывались за
этим термином реальные проблемы и недоработки подрядчиков.
2)
Разобраться с ответственностью. Кто отвечал за проект, кто принимал и подписывал
работы. Определить проблемные участки, назначить сроки и ответственных. По итогам
принять решение (депримировать\уволить\др.виды поощрения и взыскания).
3)
4)
Провести аналогичную работы с подрядчиками, возможно, доработать договоры.
Начать поэтапный запуск (реальный ввод в эксплкатацию): аппаратная часть, затем начинать
работать в новой системе по отделам, в «боевом» режиме, .начиная с самых не критичных.
Степаненко Алексей
1. Вернуться к эксплуатации старой системы, иначе можно потерять клиентов и репутацию.
2. Не нужно переходить на новую систему, если она полностью не прошла тестирование и не
получены положительные результаты от опытной эксплуатации.
3. Составить все акты с указанием недостатком при сдаче каждого этапа в эксплуатацию и
подписать их у подрядчика.
4. Доработать систему, чтобы она функционировала без сбое и только после этого вводить ее
в промышленную эксплуатацию.
Тинаев Юрий
Как правило, подобные системы внедряются параллельно с действующей. Т.е. кроме ИТ
подразделения огромная нагрузка и на все отделы компании. Плюс одновременная замена
платформы…
1.
ИТ – директор обязан объяснить руководству происходящее до полного понимания и
получения поддержки. Руководство должно знать
2.
a.
какое преимущество получит компания
b.
насколько технически сложная работа происходит
c.
где наиболее узкие места и перспективы их укрепления (от чего зависит)
Совместно с ключевыми сотрудниками проанализировать изменения бизнес процессов
компании
3.
a.
Определить наиболее критичные для бизнеса места
b.
Продумать схемы дублирования на время тестовой эксплуатации
Проанализировать старую и перспективную ИТ архитектуру
a.
Разработать план замены оборудования в зависимости от этапов работ по
внедрению новой системы п.2
b.
Выявить места возможного совместного существования новой и старой
архитектуры
4.
Лично согласовывать с руководителями подразделений все шаги, выясняя наиболее
критичные временные рамки, когда требуется максимальная мобилизация ИТ службы
5.
Разбить внедрение нового приложения и переход на новую платформу на фазы
a.
Центральный офис
i.
b.
Бухгалтерия
ii.
Отдел работы с клиентами
iii.
руководство
Филиалы(смежные компании, удаленные подразделения)
i.
На базе центрального офиса
организовать обучение ключевых сотрудников
ii.
Обеспечить технические
iii.
Сформировать контрольный
мероприятия в филиале
пример по действующей схеме
iv.
Контрольный пример по новой
схеме
v.
Передача на
сопровождение
6.
1.
Технологическая поддержка из центрального офиса
2.
Техническая – удаленная команда
Обсудить с разработчиком и вендором
a.
Сложившуюся ситуацию
b.
Предложить на основе вышеизложенного корректирующий план работ
c.
Если работоспособность нового приложения зависит от платформы, значит
первый шаг замена платформы и тестирование в новых условиях. В противном
случае возможны параллельные работы
7.
Выработать этапы работ: ИТ-директор, ключевые сотрудники, разработчик, вендор
a.
Приемку этапа осуществлять в конкретном подразделении, сравнивая с
дублирующей системой. При этом сотрудники подразделения выполняют все
процедуры согласно бизнес процесса, без фраз: «это мы поправим».
b.
Принятые этапы документировать, где отражать изменения ТЗ,
запланированные доработки
c.
Непринятые этапы фиксировать актом, в котором показаны ошибки,
несоответствия ТЗ, ошибки проектирования, планируемые сроки устранения
d.
Принятые этапы передавать на сопровождение удаленной команде. Это
позволит службе поддержки без аврала перейти на обслуживание всего комплекса.
Угольков Андрей
Последовательность действий ИТ директора могут быть такими:
1) Разделение проекта на два разных во избежание влияния ошибок аппаратной части на
программную и наоборот
2) Документирование всех этапов по обоим проектам
3) Согласование зависимостей и условий между проектами (требования программной части к
аппаратной)
4) Привлечение к проекту по модернизации аппаратной части сторонних специалистов, ранее
успешно внедрявших похожие решения (помимо специалистов вендора)
5) Разработка и тестирование нового приложения на старом, стабильно работающем оборудовании
с учетом п.3
Что это даст:
 Уменьшение простоя в проекте разработки нового приложения из-за ошибок аппаратной
части
 Более явное выявление причин простоя и способов их устранения
 Возможность привлечения/замены ресурсов (документирование)
 Повышение экспертизы за счет практиков внедрения (специалисты вендора как правило
теоретики)
Независимость этапов каждого проекта от другого до их завершения.
Федько Виктор
Не очень понятно задание кейса. Надо написать, как действовать с самого начала или что делать
теперь, когда все зашло в тупик?
С чего начать
1. Предпроектное обследование все региональных подразделений на предмет используемых
ИТ-сервисов. Нужна ревизия всего ПО и описание всех БП. Особенно, по уже
присоединяемым подразделениям
2. Подготовка полномасштабного ТЗ на новую систему с описанием всех задач и
требованиями к программно-аппаратному обеспечению.
3. Выбор системы. Если речь идет о приложении, обрабатывающее финансовые
транзакции, рассылающее и выдающее на руки счета и контролирующее их оплату,
то не надо ничего разрабатывать. В этой части есть масса готовых систем от разных
уважаемых вендоров. Достаточно будет легких доработок. Если это медицина, то там речь
пойдет еще , по всей видимости, о функционале «Амбулаторная карта», Запись на прием ,
рассылка результатов анализов и всего остального медицинского. Если в компании есть
еще и клиники – то необходим функционал 2АСУ-Больница». Таких систем тоже
множество, есть из чего повыбирать. Таким образом, мы говорим о внедрении готовых
систем (с доработками).
4. Выбор аппаратного обеспечения.
При наличии ТЗ выбирается «железо» и сетевое
обеспечение под него, с заделами на будущее. Потом выбор вендора и т.п. Все это
классика пока. Не очень понятно вот это - технический директор решил, что
….необходимо докупить инновационное аппаратное обеспечение. А CIO тогда тут
причем? Только он может и должен решать, что покупать, как и вообще надо ли,
5. Выбор подрядчика на основе ТЗ. Если мы сейчас говорим о финансовой медицинской
системе, то задача упрощается
значительно. Пусть будет региональный, недорогой,
подрядчик. Внимательно только надо посмотреть его компетенции, опыт.
6. Спроектировать ЦОД, закупить оборудование, развернуть, запустить
7. Подготовить каналы связи, сетевое оборудование, оттестировать, сдать в эксплуатацию.
Проверить скорость, безопасность.
8. Провести выверку и обработку всей нормативно-справочной информации (НСИ). Это один
самых важных факторов, который потом будет влиять на все. Соотнести правила ведения
НСИ в новой системе с уже имеющейся старой НСИ. Подготовить , если нужно, систему
перекодировки. Написать подробный план миграции, размещения, выверки и поддержки
НСИ в новой системе с момента миграции.
9. Развернуть финансовые приложения в новом ЦОДе, настроить, залить НСИ. Определить
«День Х», когда в новую систему будут залиты старые данные и с какого дня новых
клиентов будут заводить только в новую систему.
10. Разработать пилот для одного подразделения, которое создалось с нуля, и на нем провести
тестирование новой системы. Заводить
клиентов, начать выписывать счета, контроль
оплаты. Возможно, создать «тестовое подразделение» , наполнить данными и на нем
обкатать. Чтоб не на живых людях. Затем, после опытной эксплуатации в «День Х»
провести миграцию и запустить все сервисы на новой системе.
11. Все шаги документировать постановками задач, Актами сдачи, программами методики
испытаний. Сохранять все журналы тестирования, логи и т.п.
12. Обратить особое внимание на информационную безопасность – в медицине это особенно
актуально. Персональные данные на самого открытого характера. Нужны устойчивые
защищенные каналы связи, защита рабочих мест, серьезное распределение прав доступа.
Идентификация пользователей по разным параметрам. Это отдельный сегмент при
проектировании такой системы. Тут, возможно, потребуется дополнительный подрядчик,
специалисты иного уровня.
13. Принимать у подрядчика каждый блок по документам после тестирования , на основе ТЗ и
постановок задач. Определить параметры тестирования и требования к функционированию
ПО – скорость, надежность, возможность отказов.
То есть, необходима программа
методики испытаний.
Примечания
1. Некоторые пункты можно делать параллельно. Все зависит от квалификации персонала и
финансовых возможностей.
2. Здесь обсуждалось внедрение только финансовой медицинской системы. Если речь идет о
дополнительном функционале 9см. п.3), то все гораздо сложнее.
Как нормализовать ситуацию, если зашли в такой тупик
Если ИТ-директор вкупе с техническим директором зашли в такой тупик, то, скорее всего,
нормализовывать ситуацию будут уже другие люди.
1. Остановить проект
2. Поднять ТЗ и посмотреть на сделанное с точки зрения соответствия ТЗ.
3. Понять, почему происходят сбои в системе. Тут возможны следующие варианты :
3.1 Некачественная разработка прикладного ПО .Хотя, если внедряется стандартная
функциональность, то это вряд ли.
3.2 Провести тестирование «железа» и системного на предмет соответствия ТЗ и заявленным
задачам. Скорее всего, там не все соответствует. Не может перезапуск системы
производится по 6-8 часов. Не должен.
4. «Отмотать» историю проекта назад и посмотреть , с чего начинал подрядчик. Какие он
делал предложения, как он работает с НСИ.
5. Пересмотреть проект ЦОДа – здесь возможны серьезные ошибки.
6. Возможно, что в ходе проверок придется сменить подрядчика.
7. CIO должен принять решение – либо продолжать
текущий проект по новым,
разработанным правилам, либо сменить подрядчика и начать с п.1 Раздела «С чего
начать». Оба варианта возможны, надо считать затраты и в том и в другом случае.
Ошибки, заложенные при проектировании потом могут обернуться серьезными потерями
денег и репутации в будущем. Может быть стоит все начать сначала.
8. Если принимается решение продолжать, то необходимо выстроить новые правила и
постараться плавно перейти на внедрение с п.8 раздела «С чего начать». При условии ,
конечно, что вся техническая часть проверена, каналы связи и прочее соответствуют.
Цуприков Сергей
1. Создать четкий план работы по внедрению системы ( в т.ч. миграции со с тарой ан новую) с
детализацией по трудозатрататам и возможностью поэтапного внедрения с минимизацией объема
переделок системы (лучше всего используя еженельные итерации по Agile SCRUM).
2. Внедрить оптимальную систему ПСИ, при которой исполнитель несет обоснованную
ответственность перед заказчиком за результаты внедрения каждого этапа, и все они
документируются оптимальным образом.
3. Внедрить систему мотивации своего персонала для ускорения работ и повышения их качества.
4. Рассмотреть возможность дополнительного привлечения ресурсов (людских и финансовых)
либо их перераспределения (например, передачу части работ субподрядчику, сокращение
функционала новой системы либо сдвиг наименее важных этапов на более дальние сроки) либо
сокращения объемов работ.