Ежегодная конференция-выставка по теме электронного документооборота и управления информационными ресурсами

DOCFLOW 201420мая

Борьба интересов и противоположностей: как капля здравого смысла может спасти проект внедрения СЭД?

Кто мы?

• Юлия Ерина, руководитель отдела аналитики i-Sys• Артём Хахалин, руководитель проектов i-Sys

Как измеряется успешность IT-проекта

• За 8 лет количество успешных проектов увеличилось, но цифры по-прежнему неутешительны.

• В бюджет/рамки/границы вписывается лишь 39% всех IT проектов.

Зависимость от размера

Что больше всего страдает в неудачных проектах?

Соотношение перерасхода средств, несоблюдения сроков и недоработок функционала в сложных IT-проектах.

2004 2006 2008 2010 201220%

30%

40%

50%

60%

70%

80%

90%

84%

72%

79%

71%74%

56%

47%

54%

46%

59%

64%

68% 67%

74%

69%

Время

Стоимость

Функционал

Текущая ситуация• Всего 39% IT-проектов успешны• Больше всего при неудачах страдает функционал и

тратится время клиентов• Маленькие проекты в 7 раз чаще оказываются

успешными, чем крупные

Успешен ли провальный проект?

Успешный проект -это всегда компромисс между двумя сторонами

Для клиента успех это: • Работающая система,

решающая потребности бизнеса

• Достигнутые цели• Окупаемость инвестиций

Для исполнителя это: • Сделать систему в

соответствии с требованиями и в первоначальных рамках проекта и получить за это деньги

Составляющие успеха

• Выбор платформы для СЭД в соответствии с ИТ стратегией

• Понимание целей и задач проекта• Выбор надёжного вендора • Инициативная команда со стороны заказчика• Правильные коммуникации между исполнителем

и заказчиком

Анализ выполненных проектов внедрения СЭД

• Одинаковые требования к системе• Одна и та же команда от исполнителя• Одни сроки и бюджет

Но такие разные заказчики…

Команда А

НевнимательностьХаотичность

Пускают на самотёк

Команда Б

ФормализмВнимание к мелочамСкрупулёзность

- Нет сформулированных требований, ТЗ пишем ориентируясь на функционал типовой версии Системы

- Рискуем внедрить кота в мешке+ Не тратим времени на лишние

согласования+ Базируемся на типовых функциях

системы, максимально апробированных и отлаженных

- Очень долгое согласование ТЗ. Занимаемся нормоконтролем вместо согласования сути.

- Описываем «идеальную» СЭД, многим клиент не будет пользоваться, но пока этого не понимает

+ Получаем 2000 листов ТЗ, с которым можно запустить ракету в космос. Заказчик думает, что предусмотрел все.

Этап анализа требованийКоманда А Команда Б

Артефакты первого этапаКоманда А Команда Б

Этап разработки

- Разрабатываем систему по ТЗ, которое сами и сочинили. На этапе запуска в ОЭ заказчик присылает требования и мы перенастраиваем систему

+ Заказчик опытным путём понимает что ему нужно, а что нет. Не тратим время на мёртвый функционал

+ В ТЗ прописан каждый чих разработчиков, им просто и приятно

Команда А Команда Б

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

- Много замечаний, доделываем систему «на ходу»

+ Быстро устраняем все вопросы, сдаём систему в эксплуатацию

- Очень много замечаний не относящихся с функционалу (высота полей, шрифт)

- Задерживаем выход в пром, гонясь за идеальной СЭД

Команда А Команда Б

Количество обращений: 160

По делу По зову души

Количество обращений: 600

По делу По зову души

По отношению к запланированным затратам

Срок Затраты заказчика

Затратыисполнителя

Функционал

5 % 0 % 0% 10 %

30 % 20 %* 250% 60 %

В таблице указываются дополнительные затраты Заказчика (дополнительные затраты на свою команду). При этом дополнительные

затраты вендора во втором случае выросли в 2,5 раза.

Команда А

Команда Б

Учимся на чужих ошибках

Не нужно стремиться к идеальной СЭД, особенно если вы раньше не использовали

подобных систем

Применяйте итеративный подход: сначала пилот, потом проект

Не перенасыщайте систему требованиями, посмотрите как она будет

вести себя в опытном режиме. Дополнительные требования – хороший

повод для второго этапа.

Не тратьте время «дорогих» специалистов на неквалифицированные

задачи. Команда должна участвовать в проекте с равномерной загрузкой, а не

выезжать за счёт руководителя.

Не пытайтесь привязаться к интерфейсу старой СЭД – технологии уже сделали шаг

вперёд

Учитывайте собственные затраты при учете результатов проекта

Вовлекайте топ-менеджмент в работу с системой на этапе эксплуатации

Вопросы?

• Юлия Ерина, руководитель отдела аналитики i-Sys• Артём Хахалин, руководитель проектов i-Sys