Тему подняла в ECM-группе на ФБ Ольга Подолина.
"Оценка эффективности" – тема вечная и из разряда "нерешаемых в общем случае в принципе". Но при этом, глубоко убежден, которые все же нужно как-то решать..
[spoiler]
Я уверен, что как любую исследовательскую задачу, ее нужно начинать с ответа на вопрос: нужно ли ее решать? Кому это нужно и зачем?
Например, возможно, есть проблема обоснования стоимости проекта. Откуда, например, в гостендерах берутся исходные суммы на проект? Как и кем они обосновываются?
В общем-то, мне представляется почти очевидным, что свести оценку эффективности к чистой арифметике (вложил 100 руб, получили 200 руб доп. Прибыли) – это иллюзии, не более того. Но все же какие-то оценки делать нужно.
Собственно тут и встает вопрос к практикам (и продавцам и покупателям): а как вы обосновываете стоимость проекта?
Но кроме оценки экономической эффективности (или просто "эффективности") есть и другие важные показатели.
1. Оценка успешности проекта. Два крайние границы такой оценки понятны – "проект реализован" и "проект не реализован". Но между этими точками есть много промежуточных состояний – "реализован, но не полностью", "реализован, но с превышением сметы", "реализован, но с превышеем сроков"….
2. Оценка эффекта. Хочу обратить внимание; эффект и эффективность – это разные вещи (хотя и "из одной оперы").
В моей трактовке, эффект – это некоторый измеряемый результат, который определен в ТЗ, как одна из целевых задач. Что должно быть получено в результате проекта. Например, сокращение персонала, увеличение обрабатываемых запросов, повышение лояльности клиентов (по каким-то критериям),
Но на самом деле, мне видится из моего опыта общения, что с заказчиками, что с внедренцами - почти никто (по моим оценкам – 80-90%) при выполнении ИТ-проектов в реальности вопрос об эффективности и эффекте (кажется и об успешности) – даже и не ставит.
Или я не прав?
Все это интуитивно понятно, но требует некоторого осмысления. Осмысления в плане практического применения. На сегодня вокруг видится только масса людей, озадаченных необходимостью что-то куда-то постоянно вводить и отчитываться, пусть даже и электронно. Это отвлекает их от основных обязанностей, подчас всерьез и надолго. Скорее, это и недостатки оценки бизнес-процессов и не совсем корректная реализация. В любом случае, так СЭД мешать людям не должна. Весьма вероятно, что те несколько примеров, что я наблюдаю, просто действительно неудачные...
Нельзя вслепую переносить в СЭД существующие "бумажные" процессы.
А проблемы- в плохом знании методологии.
Согласно теории систем, выделяют цели и задачи. Задачи- промежуточные этапы для достижения цели.
Задачи определяются инструментами, имеющимися в распоряжении исполнителя.
При изменении инструмента меняются и задачи.
Например, цель- путешествие из Петербурга в Москву.
Ситуация 1. 19 век. Инструменты- коляска с запряженной лошадью. Задачи: найти коляску, получить подорожную и т.д.
Ситуация 2. 21 век. Инструменты- поезд, самолет. автомобиль. В зависимости от выбранного инструмента меняется набор задач для достижения главной цели.
Поэтому я вижу ошибки при проектировании информационных систем: задачи принимаются за цели!
Целью должна быть эффективная основная деятельность.
При бумажном документообороте это обеспечивается одними средствами, а при переходе к СЭД (меняем инструмент!) решаемые задачи должны быть другие!
Цель- не построение эффективного документооборота, а построение эффективной деятельности при помощи информационных систем, СЭД в том числе.
Я решаю именно эту задачу.