анализ внерения после того как ушли внедренцы

[ryzhyi_katik]

были ли у вас случаи проведения post implementation review после того, как от вас ушла команда внедренцев? Вот так по серьезному, чтобы руководство дало задание, или вы сами как внедренец пришли после какой-то команды и перед вами стоит такая задача, проанализировать, что было сделано до вас. Каковы существующие опробованные подходы и методики?

[bobkov_imported]

Цитата:

Сообщение от ryzhyi_katik

были ли у вас случаи проведения post implementation review после того, как от вас ушла команда внедренцев? Вот так по серьезному, чтобы руководство дало задание, или вы сами как внедренец пришли после какой-то команды и перед вами стоит такая задача, проанализировать, что было сделано до вас. Каковы существующие опробованные подходы и методики? 

<{POST_SNAPBACK}>

А чего там особенного - обыкновенное обследование, которое проводится на каждом проекте... :-)

[Yoil]

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

[ryzhyi_katik]

не, меня больше методики интересуют кто какие использовал при таком анализе. мне руководству надо варианты действий предоставить.

[mazzy]

Цитата:

Сообщение от ryzhyi_katik

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

<{POST_SNAPBACK}>

"Проанализировать" - процесс.
Какой вы ожидаете результат от этого процесса?
1. Тщательно разобраться и наказать кого попало?
2. Определить план работ, чтобы довести внедрение до конца?

Если 1, то зачем вам методика?
Если 2, то bobkov правильно говорит - обыкновенное обследование, где выясняется что есть и что надо. Затем вырабатывается план работ. Этот план реализуется.

[ryzhyi_katik]

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

[bobkov_imported]

Цитата:

Сообщение от ryzhyi_katik

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

<{POST_SNAPBACK}>

Я когда-то писал текстик на эту тему - попробуй почитать... :-)

Проект – совокупность связанных работ, направленных на достижения цели.
Для проектов по автоматизации управления предприятием, которыми мы занимаемся, цель определяется как совокупность характеристик автоматизируемых информационных бизнес-процессов (АИП), обычно являющихся частью бизнес-процессов управления. То есть, у Заказчика есть какие-то АИП, они необходимы ему для управления, он хочет улучшить какие-то их характеристики. При этом, очевидно, АИП должны стать какими-то другими, не такими как исходные.

Для этого требуется согласованно изменить элементы, принадлежащие обычно следующим, относительно независимым, слоям:
1. Организацию АИП, то есть их состав и связи друг с другом – может потребоваться изменение функциональных обязанностей сотрудников и их регламента работы;
2. Собственно АИП, то есть как они сейчас выполняются – может потребоваться доработка или замена бизнес-приложений, обучение или замена сотрудников;
3. СУБД, то есть формат хранения информации – может потребоваться модернизация или замена СУБД;
4. Информацию, то есть ее состав – может потребоваться конвертация и ввод данных;
5. Вычислительную и сетевую инфраструктуру, то есть компьютеры, сети – может потребоваться модернизация или замена оборудования.

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

Если для какого-то элемента согласованных изменений не требуется, то изменение такого элемента необходимо вынести за рамки проекта.

Для того чтобы спланировать проект, необходимо изучить исходное состояние элементов системы. Изучение 3 и 5 слоя обычно имеют относительно небольшую трудоемкость – это такие работы как знакомство с пользователями, изучение регламентных документов, изучение СУБД, компьютеров и сетей. Изучение 1, 2 и 4 слоя обычно имеет большую трудоемкость – это такие работы как изучение функциональный обязанностей сотрудников, регламентных документов, функциональности приложений и состава данных.