BoatmansHome: Заметки/ГлавнаяПроблемаИТПроекта ...

Boatmans Home Start | Каталог | Изменения | Комментарии | Пользователи | Регистрация | Вход  Пароль:  
Данные материалы созданы для размещения на сайте boatmanshome.ru. Во всех случаях, кроме явно оговоренных в теле материала, автор и обладатель исключительного права - Нужненко Сергей Александрович. Во всех случаях, кроме явно оговоренных в теле материала, для данных материалов разрешено размещение ссылок и цитирование, а так же воспроизведение в личных и учебных целях. Без согласования с правообладателем запрещается для данных материалов или любой части использование в коммерческих целях, а так же распространение, публичный показ, импорт с целью распространения, прокат, переработка, сообщение для всеобщего сведения.
 

Главная проблема ИТ проекта


Предыдущая лабораторная работа по качеству /Заметки/ОКачестве1 позволила зайти на тему из /Заметки/ПочемуТакДорого с другой стороны и вскрыла одну печальную мысль: время стократных и более отдач от внедрения ИТ прошло в большинстве областей применения.


Там, где моя работа сталкивает меня с ТЭО автоматизированных систем корпоративного управления, речь идет о доказанной годовой отдаче инвестиций на уровне 10–30%.
Если верить мировой статистике, лишь 30% ИТ проектов оказываются успешными. По моей личной статистике удается запустить в промышленную эксплуатацию от 15 до 30% автоматизированных систем.
Указанная отдача, скорректированная такими рисками, не покроет даже инфляцию в РФ.


Такие низкие проценты отдачи делают ИТ проект лишь одним из многих вариантов вложить средства с пользой. А (сравнительно) высокие бюджеты на такие проекты (я говорю о КИС, в своей области смотрите сами) заставляют собственников и первых лиц компании задуматься, стоит ли уменьшать прибыль в пользу высокорискованных мероприятий с низкой отдачей?


Дальше происходит самое интересное. Проекты продаются «в бане» или, как говорят коллеги, «продажники втюхивают систему» и проект (если не дай бог он все же стартует) надолго остается без четких целей. Так как редко у команды и заказчиков хватает мужества официально записать в устав «мы боремся за штампик [SAP onboard]" или «надо утилизировать 10000 лицензий, которые мы уже купили».
Истории, когда заморский консультант помог компании осознать эти цели, вписать в устав, и тем самым сделал проект очень успешным, я пару раз слышал за пивом от коллег.


При этом все наиболее четкие цели ИТ проекта явно вытекают из качественного подсчета ТЭО, в котором доходная часть прямо указывает на объемы, степень и качество требуемой автоматизации.


Отсюда ряд соображений.
1. Плохая новость: если ваш проект не декларирует кратное увеличение оборотов компании или кратное сокращение штата, он, вполне возможно, низкорентабельный. А значит, без ТЭО. А значит без ясных и четких целей. А значит и без ясных требований.

Прошу понять меня правильно, финансовые цели – это не единственно возможные цели. Но для бизнеса они самые частые. В тех редких случаях, когда проект достигает большую стратегическую цель (например, устойчивая связь в рамках страны, подвергшейся массированной ядерной атаке) тоже есть, где брать требования к системе. При этом еще Брукс писал о сомнительных успехах разработки OS/360. И вот вопрос: какие цели были у этого проекта кроме «получить OS/360» и что там с ТЭО?

2. Хорошая новость: это создает рабочие места для аналитиков и не только для них.


3. Вопрос о ТЭО проекта поможет аналитику не только потроллить заказчика или менеджера проекта, но и быстро найти и зафиксировать те общие исходные точки, от которых можно направить сбор требований и с помощью которых можно эти требования приоритезировать и окончательно утвердить (и защитить) рамки системы.


4. Даже если на этот вопрос не получится ясный и четкий ответ, задав его, мы получим множество полезной информации. А в случае, когда эта информация будет заключена во фразе «мы не знаем», открывается дорога к разрешению заказчика немножко поисследовать и предложить варианты, то есть к концептуальной проработке системы.


5. От проектов с высокой отдачей инвестиций не отказываются. У вас нет денег на реализацию проекта с доказанной тысячекратной отдачей? Возьмите кредит или найдите инвесторов.


Естественно, проблемы с отдачей находятся в слове «доказанной».
И тут есть как объективная сторона – мы говорим о будущем, которое не знает никто, так и субъективная сторона, выраженная в вопросе «сколько человек мы сможем уволить».


Те, кто был или живет в Москве, возможно видел лежачий небоскреб на Варшавском шоссе.
Мне оттуда в студенчестве отец (спасибо ему) достал отличный немецкий кульман по остаточной стоимости.
А дело было так.
В этом доме длиной 736 метров расположен НИЦЭВТ. И раньше там этажами сидели конструктора, технологи, чертежники, расчетчики, бухгалтерия. И занимали по целому, по половине или по четверти этажа.
С приходом автоматизации (и перестройки) этажи опустели, в небольших закутках остались парни с Автокадом, тетя клава с 1С и непонятные люди с каким-то расчетным софтом.
Заполнение здания уменьшилось до 10–20%.
Старую технику сдвинули в угол, освободив громадные площади под сдачу в аренду. А тут у меня как раз началась начертательная геометрия и папа пошел по магазинам в поисках достойного реквизита, закончив свои поиски в НИЦЭВТ.
Дело не только перестройке и падении промышленных объемов. Такую же картину я видел во многих административных корпусах работающих заводов. Люди уходили этажами, так как, например, вместо этажа бухгалтерии, ту же работу делали 2–3 тетки в 1С или подобной системе. А вместо пары чертежников на конструктора вполне справлялся сам Автокад.

И еще немного об экономике ТЭО.
Допустим, вы продаете систему со средней сметой X, а точнее учтите, что у нее есть полная стоимость владения Y, кратно большая, чем X. Учитывая риски ИТ проектов эту цифру (грубо) нужно умножить на 3–6.
А чтобы получить приличную годовую отдачу инвестиций, надо умножить эту цифру хотя бы на 1,5–2, что за пятилетку должно составить возврат в размере х7-х32. Причем при отдаче всего лишь в 50% в РФ у бизнеса и собственников масса альтернатив вложения средств.


Итого, ваш бюджет нужно умножать на 6*32=192, то есть примерно 200. А с учетом полной стоимости владения и на все 400–500.
И наоборот, доказанную выгоду за пять лет надо делить на 400–500, чтобы получить естественное ограничение бюджета внедрения.


Теперь пойдем с другой стороны. Без привлечения кредита и ущемления собственников компания может потратить на систему проценты (допустим, 5% и это очень много) от прибыли (норма которой у нас должна быть от 30–50% или четверть-треть оборота). То есть 25–30*0,05=1,25–1,5% с годового оборота.
Какой возврат мы должны обещать через 5 лет? 1,25*400=500% от годового оборота или 38% годовых, а лучше больше.


Скорее всего на растрату 5% прибыли придется отстаивать проект перед собственниками компании (если сделать все честно). Когда нужны вложения, превышающие прибыль, придется лезть в кредит или искать инвестиции, и тогда защищать проект придется уже в банке или перед инвесторами.
Но какой возврат вы должны обещать, если склоняете компанию потратить всю прибыль на ИТ? Для представленных выше чисел у меня получается 6–7кратный годовой рост (и сокращение издержек уже не поможет).


Это, наверное, причина развития многих проектов методом каши из топора, когда разные части расходов на ИТ размазываются между капитальными и операционными без выхода к обсуждению системы как системы и ее полной стоимости владения.


И еще ряд соображений.
1. Спросите про ТЭО и ожидаемое ROI системы на старте проекта. То, что вам скажут, а главное, как скажут, дает много пищи для ума. Если там доказанная отдача в сотни процентов – ныряйте не раздумывая – этот проект скорее всего получит отличную поддержку.


2. Имея публичный бухгалтерский отчет компании вы можете достаточно точно установить как ограничения по бюджету вашего проекта, так и желательный возврат инвестиций. И можно никого не спрашивать.


3. Когда вас спросят о ТЭО вашего проекта, не пугайтесь, расчеты выше говорят нам, что большинство современных ИТ проектов далается не для ROI. Можете сразу сказать, что не собираетесь стимулировать отдачу до половины оборота в год, иначе бы вы сидели в кресле своего начальника, а то и выше (тут необходимо смягчать формулировки). И дальше предложите вместе поискать выгоды и цели проекта, которые всех устроят.


4. Расчеты выше, переделанные под среднезападные условия: нормы прибыли в 5% и отличный возврат инвестиций в 15% дают такие цифры:

Это дает представление, почему западные системы и подходы (ERP, CRM, Docflow и т.п.), у нас взлетают реже, чем там (и да, дело не только в отечетвенном бардаке и неумении управлять).

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


P.S.
Первые, прочитавшие эту заметку сказали, что она грустная и безысходная.
Но я хотел сказать не это.
Дело в том, что именно для выковыривания эффективных требований в век падающей отдачи от ИТ и нанимают аналитиков. С одной стороны легко не будет, а с другой мы точно знаем, где искать наиболее эффективные требования и как встраивать систему в бизнес:
1. ищите наибольшую экономию или возможности роста;
2. с бизнесом необходимо вести диалог о мерах по вычерпыванию создаваемых резервов оптимизации (например, с точки зрения бизнеса глупо сокращать трудоемкость операций, если пользователей не собираются догружать или сокращать.
3. Тут становится ясно, что требования к ИТ лучше всего начинать собирать с выяснения стратегического движения организации – что она делает: собирается растить выручку или сокращать издержки, какие подразделения и процессы будут развиваться, а какие усыхать, что будет с организацией через 3 года и, желательно, в деньгах.
4. И вот оно: здравствуй, корпоративная архитектура!


 
Файлов нет.[Показать файлы/форму]
Комментариев нет. [Показать комментарии/форму]