Главная Без рубрики, Новое Проблемы оценки экономической эффективности IT проектов (Часть1 )
  • Проблемы оценки экономической эффективности IT проектов (Часть1 )

    image006Внедрение решений в области IT нередко требует реорганизации компании, изменения бизнес – процессов и, как следствие, существенных инвестиций. Несомненно, возникает вопрос целесообразности этих затрат и методики оценки эффективности информационных систем предприятия.

      

    Парадокс Эрика Бринэльфсена.

    В 1996 году в сентябрьском выпуске научного журнала "Information System Research" появилась статья Эрика Бринэльфсена (Eric Brynjolfsen) "The Contribution of Information Technology to Consumer Welfare", что можно вольно перевести как "Вклад информационных технологий в рост благосостояния потребителей". К сожалению, в России она не настолько известна, хотя значение ее для IT сообщества до сих пор колоссально. Ключевой вывод, сделанный в этой статье заключается в том, что несмотря на очевидное влияние IT на рост благосостояния потребителей, точная оценка того насколько велико это влияние – не представляется возможной. Т. е. можно говорить лишь о некоторой оценке.

    Таким образом, возникает «недопонимание» между финансово-экономическими отделами компаний, которые выделяют деньги и IT отделами, которым приходится обосновывать экономический смысл внедрения тех или иных проектов. О чем идет речь? Новое IT решение, безусловно, должно приносить компании какие-то выгоды, иначе оно нецелесообразно. Разумеется, я не рассматриваю «специфику» некоторых российских IT проектов последних лет, у которых были совсем другие задачи. В принципе, возможно, рассчитать затраты. Основная проблема заключается в оценке экономических преимуществ, которые принесет внедрение нового проекта. Простейшая экономическая формула говорит нам, что проект успешен, если (затраты на проект – выгоды полученные от проекта) > 0 – проект успешен, если <0, проект принес убыток компании. Бринэльфсен наглядно доказал, что не существует никакого очевидного метода, чтобы напрямую посчитать выгоды от внедрения IT решения. С 1996 года прошло уже больше 16 лет, но никто в научном сообществе так и не смог предложить внятного решения "Парадокса Бринэльфсена".

    Тем не менее, ни один серьезный IT-проект не обходится без оценки экономической эффективности. Несмотря на то, что напрямую вычислить выгоду невозможно, существуют «обходные» методы решения этой проблемы.

     

    Краткий обзор некоторых методов оценки эффективности IT-проектов

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

    К сожалению, наиболее простой сравнительный метод оказывается наименее применимым для оценки, именно IT-проектов. Чрезвычайно сложно сравнивать IT-инфраструктуры разных компаний, как правило, имеющих совершенно разные, специфические требования, разные масштабы и задачи. Без преувеличения можно сказать, что практически каждый крупный IT- проект может быть абсолютно уникальным. При этом следует иметь в виду, что и получение интересующих нас финансовых и иных данных по другим компаниям для анализа будет представлять, по сути своей, неразрешимую проблему, поэтому сравнительный метод оценки экономической эффективности IT-сообщество чаще всего избегает. Оставшиеся два основных метода: затратный и доходный, имеют существенные ограничения, тем не менее, являются международно признанными, и, соответственно разумно будет их рассмотреть.

     
    Анализ TCO

    К затратному методу может быть условно отнесена оценка по TCO (Total Cost of Ownership – Совокупная Стоимость Владения), которая была разработана в 1990-х годах исследовательской компанией Gartner Group. Цель – дать возможность компаниям сопоставить стоимость решений различных поставщиков. Под показателями ТСО подразумевается сумма прямых и косвенных затрат организации на внедрение эксплуатацию информационных систем.

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

    Следует иметь в виду, что в отличие от бюджета на IT, который рассматривает только непосредственные, «прямые» затраты на IT, в методике анализа по TCO также учитываются опосредованные или «косвенные» затраты. Рассмотрим пример непосредственных или прямых затрат. При внедрении средств автоматизации управления жизненным циклом программного обеспечения, скажем с помощью групповых политик AD или SCCM, мы, очевидно, сокращаем затраты на управление и поддержку ПО, что легко поддается экономической оценке. К косвенным затратам относятся потери времени персонала на обучение, самостоятельное решение проблем с информационными системами (без привлечения службы технической поддержки), потери времени сотрудников на помощь коллегам, а также потери компании от возможных сбоев и недоступности информационных систем.

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

     
    ROI

    Другой метод расчета, также широко используемый IT-сообществом можно условно отнести к доходному ROI (Return On Investment – Возврат на Инвестированный капитал).

    Его основная формула выглядит следующим образом:

    image

    где Gain of investment – прирост инвестиций, Cost of investment – стоимость инвестиций.

    ROI есть ни что иное, как отношение чистой прибыли от реализации предполагаемого проекта к его общей стоимости. Скажем, если мы получили ROI от IT-проекта в 300%, то это значит, что на каждый вложенный в проект рубль, мы получили еще три чистой прибыли и вернули наши инвестиции.

    Этот метод служит для расчета рентабельности инвестиций на внедрение информационных систем и рассчитывается исходя из затрат на внедрение новых технологий и снижения других расходов компании после того, как проект будет реализован. Анализ рентабельности инвестиций осуществляется на продолжительном временном интервале, обычно речь идет о трех-пятилетнем периоде. Разумеется, следует постараться учесть возможные риски и проводить расчеты, используя дисконтированный денежный поток. Кроме того, необходимо иметь в виду, что механизмы расчета не являются абсолютными и могут изменяться с тем, чтобы более полно отражать текущее положение вещей. То есть, строго говоря, не существует «правильной» методики. Очень многое зависит от того, что именно, будет включаться в доходы и расходы, таким образом, конечный результат существенно зависит от того удалось или нет выделить все факторы, воздействующие на финансовый результат. А эта возможность для IT-проектов вызывает сомнения…

     

    Подведем итоги…

    Какой из рассмотренных методов даст лучшие результаты? К сожалению, на этот вопрос нет однозначного ответа. Оба метода для целей IT являются очень приблизительными и более того, дадут совершенно разные цифры экономической эффективности. Почему это происходит? Дело в том, что один метод пытается оценить затратную часть в долгосрочной перспективе, другой – доходную на определенный временной интервал. Если TCO, в принципе, мы можем рассчитать, то в ROI мы опять встречаемся напрямую с проблемой Бринэльфсена, с оценкой "Gain from Investment" (Выгод от вложенных денег). Значит ли это, что мы должны отказаться от использования рассмотренных методов при оценке экономической эффективности IT-проектов? Разумеется, нет. Тем не менее, мы понимаем, что каждый из них имеет ограничения, которые следует учитывать. Примеры расчетов TCO и ROI мы рассмотрим в следующих статьях цикла.

    Хотелось бы отметить, что компания Microsoft разработала свою крайне интересную методику – REJ (Rapid Economic Justification), в которой предлагается разделять "Gain from Investment" на две части: "Business benefits" и "IT operation savings". После чего, применяя дисконтирование денежного потока посчитать NPV (Net Present Value, Чистая Приведенная Стоимость) и IRR (Internal Rate of Return, Внутренняя Норма Доходности). Методика REJ очень сложная и не может быть рассказана вкратце. Это тема для отдельной серии статьей.

     

    Литература

    [1] Erik Brynjolfsson The Contribution of Information Technology to Consumer Welfare. //1996

    [2] Tracy Mayor A buyer’s guide to IT value methodologies // CIO, July 15, 2002

     

    Статья опубликована в журнале “Бизнес & Информационные Технологии” Выпуск № 2 (25) 2013 г.

    Алексей Лагутенков,

    Леонид Шапиро.

Комментарии

  1. В последнее время развелось много “специалистов”, которые прочитают 2 статьи в экономике и начинают считать себя гуру. Психологи-экономитсы, сисадмины-экономисты, на конференциях только что с уборщицами-экономистками не сталкиваешься :).

    В статье перевран не только смысл работ Erik’а Brynjolfsson’а, но даже и его фамилия (некто Brynjolfsen). Собственно единственную пользу, которую может извлечь читатель из статьи – это косвенная ссылка на весьма компетентного исследователя, действительно мало известного в России.

    В остальном, представления автора находятся на уровне теории о прибавочной стоимости. Да и то, автор зачем то противопоставляет ROI и TCO. Уровень проработки материала очевиден из списка литературы из двух позиций.

  2. В последнее время развелось много «критиков», которые считают, что они что то знают и более того, что их мнение кому то интересно. Александр, где можно с вашими трудами познакомиться? Или вы по принципу “чукча читатель” ?

  3. По содержанию, я категорически не согласен с главным постулатом статьи, а именно, мнением о том, что невозможно точно подсчитать экономическую эффективность ИТ проекта. Ещё как возможно и уже неоднократно выполнено!

    Другое дело, что в России, экономическая эффективность ИТ проектов, действительно, не редко не являлась главной целью, как правильно отмечено в статье, а именно “«специфику» некоторых российских IT проектов последних лет, у которых были совсем другие задачи”. По этой причине, экономическое обоснование часто выполнялось “для галочки”, что в итоге привело к полному размыванию понятий и методов оценки эффективности, которые сознательно искажались для получения “нужных выводов и цифр”.

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

  4. Андрей, насчет точного подсчета экономической эффективности ИТ проекта…
    Было бы крайне любопытно увидеть такую методику. Возможно, ли предоставить какие-то материалы? Я с подобным пока не встречался.
    Я могу сослаться на работу Erik Brynjolfsson The Contribution of Information Technology to Consumer Welfare. //1996, где как раз говорится об обратном.

    По второй части замечания, насчет извлечения прибыли от проекта, мне представляется весьма непростой как раз оценка этой самой прибыли, особенно, когда мы говорим о “внутреннем” проекте. Выделить вклад этого проекта в формирование выручки предприятия крайне затруднительно. Да и с “внешним” проектом тоже не все так просто, поскольку реальные цифры мы можем увидеть, по сути, только постфактум.

    Примечание:
    «Внутренние» или инфраструктурные проекты – проекты, которые не связаны напрямую с входящим денежным потоком компании.
    «Внешние» проекты генерируют входящий денежный поток.

  5. Леонид, отвечая на твои комментарии, могу пояснить следующее:
    1) Методика подсчёта экономической эффективности ИТ проектов (как внешних, так и внутренних) состоит в том, чтобы тщательно подсчитать все расходы и трудозатраты в рамках бизнес-процессов “AS IS” и “TO BE” сразу за весь планируемый цикл жизни внедряемого решения и вычесть первое из второго (также не забыть вычесть из результата ещё и первоначальную стоимость перехода к модели “TO BE”). В компаниях, где все бизнес процессы “AS IS” в ИТ отлажены (например по ITIL), уже есть все метрики и статистика. А процесс перехода к “TO BE” и дальнейшего функционирования решения представляет собой прогнозируемые действия, затраты на которые можно подсчитать (с точностью до прогноза рынка (будущей нагрузки в рамках рассматриваемых бизнес процессов)).
    2) Прибыль (исходя из п.1) является прогнозируемой величиной (с той же оговоркой на прогноз рынка по объёму (желающие могут сделать более точный прогноз по ценам, но я видел только вариант с фиксированной ценой)) и фактически подсчитывается в этих рамках.

    P.S. Поскольку подсчёт экономической эффективности выполняется до внедрения проекта, все полученные величины являются прогнозируемыми (планируемыми). Реальные цифры можно получить только постфактум в рамках аудита ИТ процессов на основе метрик (KPI), и учёта динамики реальных цен, но это уже другая тема.

  6. Уважаемый Андрей,
    Позвольте внести свою лепту.
    1) Давайте перейдем от теории к практике. Пусть существует гипотетическая компания, которая владеет внедренной «1С», но хочет внедрить «SAP». На 1С программистов, поддержку и все остальное, пусть тратится $3’000 в месяц. Внедрение SAP позволит предприятию получить полноценный ERP, CRM, ну и еще, что там они хотели. Реинжиниринг бизнес процессов до TOBE, внедрение, обучение обойдутся компании в $2’000’000, плюс поддержка этого комплекса в $50’000 в месяц. Пусть внедрение 1С в свое время обошлось компании в $30’000. Согласно Вашему методу («AS IS» и «TO BE»…, вычесть первое из второго) , вычитаем из TOBE SAP – ASIS 1C. Пусть 1С проработал 3 года, и столько же предполагается проработает SAP. (2000000+50000*12*3)-(30000+3000*12*3)=$3’662’000. О чем говорит нам эта чудовищная цифра? Лично мне ни о чем, кроме того, что затраты на переход будут астрономическими.
    2) Скорее не прибыль является прогнозируемой величиной, а выручка. Прибыль штука слишком многофакторная и размазанная во времени, чтобы ее можно было как-то более – менее вменяемо прогнозировать. Допустим, компания планирует, что выручка за этот год вырастет на 10%, при этом затраты на IT после внедрения нового проекта выросли допустим с 1% выручки до 10%.Что случится с прибылью? Прибыль, очевидно, упадет. Внедрение нового проекта было вредным? Вовсе нет. Внедрение, обучение персонала, временной лаг перезапуска бизнес-процессов может составить и год ,и два, и три для крупной компании. Возможно, через 2 года, внедренное решение будет сильно снижать трудозатраты. Но если считать это затратным методом (TCO) для бухгалтерии, получится, что проект принес компании на текущий год чистый убыток.
    По пост скриптуму. Реальные цифры эффективности нельзя получить ни постфактум, ни на основе аудита, ни на основе KPI. Затраты – да, получим легко, но не эффективность. Мы уже посмотрели цифры перехода с 1С на SAP. C точки зрения цифр затрат – проект мегаубыточный, но KPI ITIL покажут полную идиллию: упадут инциденты, проблемы, вырастет доступность ну и так далее. То есть все хорошо, кроме того, что раньше на это все тратилось $3’000 в месяц, а теперь тратится $50’000 в месяц. Очевидно, что работать все стало лучше, но затрат стало больше. Выручка, как планировался рост в 10%, так она и растет по 10% вне зависимости от внедрения. Проект был глупым и убыточным? И да и нет. Невозможно ответить. Невозможно выделить в выручке ту часть, которая именно приносит доход от внедренного проекта. Затраты видны и считаемы, а прибыль нет. Компания запустила линейку новых продуктов, новую маркетинговую компанию, внедрила крупный IT проект, провела реструктуризацию. Выручка выросла на 12% вместо планируемых 10%. Как выделить в этой куче роль и значение IT? Никак. Затраты – пожалуйста. И совершенно верно, можно посчитать разницу TCO TOBE (SAP)и TCO ASIS(1C). Она будет чудовищной, но явно внедренный продукт лучше, явно обслуживание лучше, но найти хотя бы точку безубыточности внедрения, не представляется возможным.
    Поговорить об эффективности внедрения IT проекта может только очень крупный вендор, который имел полный доступ к финансовой информации предприятий, на которых проводил внедрения и внедрил статистически значимое (ну пусть больше 33) количество одинаковых проектов. В этом случае вендор может поиграться со статистической регрессией, на основании которой может дать предположительные прогнозы эффективности внедрения на похожем предприятии. Это сравнительный метод оценки, для него жестко нужны статистические данные. Насколько я знаю, эта методика настолько сложна, что даже крупные вендоры стараются ее аутсорсить сторонним научным расчетным организациям.
    Надеюсь, что не утомил своим занудством 🙂

  7. Уважаемый Alerter!

    Благодарю за опубликованный пример проекта, но, к сожалению, представленные в нём данные не полны, поэтому не позволяют осмысленно расчитать экономическую эффективность внедрения SAP.
    Известно, что в стоимости внедрения ИТ решений, к которым, безусловно, относиться внедрение продуктов SAP, самую значительную часть составляет фонд оплаты труда (ФОТ).
    По оценкам [1] IBM доля ФОТ в себестоимости продукции при использовании труда американских рабочих составляла 57%, а индийских – 47%. Зарплаты ИТ специалистов в Москве ниже американких, но выше индийских, поэтому эмпирически примем долю ФОТ в себестоимости продукции для Москвы 50% (именно эту цифру я закладываю в расчёты экономической эффективности, когда делаю это сам).
    Процесс внедрения внутреннего проекта, если он осуществляется ради достижения экономических целей, а не для “решения совсем других задач”, как было отмечено в статье, направлен в первую очередь на повышения производительности труда персонала с целью снижения доли ФОТ в себестоимости продукции.
    Таким образом, подсчёт экономической эффективности внедрения без знания количества персонала, занятого в бизнес процессах, направленных на выпуск дополнительных 10% продукции не возможен.

    Разберём 2 варианта внедрения:
    1) Компания дистрибутор из 10 человек переходит с 1С на SAP
    2) Компания дистрибутор из 1000 человек переходит с 1С на SAP

    Цикл жизни, себестоимость внедрения и обслуживания взята для второго примера из Ваших цифр.
    В целях существенного упрощения примем, что проект исключительно внутренний и новых продуктов Заказчику не предоставляет, а лишь увеличивает производительность персонала (продавцов и т.п.).
    Ввиду упрощения выше, прогноз прибыли от увеличения выпуска продукции и доли в нём ФОТ можно исключить.
    Также для упрощения весь персонал компании дистрибутора считаем на 100% задействованным в увеличении выпуска продукции, причём в равной степени (водители – возят, грузчики – грузят, бухгалтерия – выставляет счета, продавцы – оформляют договора).
    Увеличение производительности труда персонала при переходе от 1С к SAP – 100% (вообще-то надо смотреть, какие модули внедряются и замерять время выполнения типовых операций в 1С и SAP, но здесь для простоты примем в качестве “среднего по больнице”).
    Стоимость внедрения (лицензии) и обслуживания (часы поддержки) на одного клиента увеличиваются линейно.
    Доля стоимости внедрения и поддержки ядра системы 50% от CAPEX и OPEX.
    Средняя зарплата в компании $3000 в месяц.

    Экономический эффект от внедрения 1 варианта (10 сотрудников):
    За счёт увеличения производительности труда на 100% при одновременном увеличении выпуска продукции на 10% экономим 1 ставку.
    За счёт меньшего количества персонала (в 100 раз) коэффициент клиентских затрат по CAPEX и OPEX равен 0,01, а приведённый, соответсвенно 0,5+0,01=0,51.
    ($3000*1*12*3)+($3000*0,51*12*3)-($2000000*0,51+$50000*0,51*12*3)=$108000+$55080-$1938000=-$1774920
    Как видим, при больших начальных затратах и эксплуатационных расходах предлагаемого решения в случае внедрения проекта получим чистый убыток, следовательно внедрять смысла не имеет.

    Экономический эффект от внедрения 2 варианта (1000 сотрудников):
    За счёт увеличения производительности труда на 100% при одновременном увеличении выпуска продукции на 10% экономим 50 ставок.
    Итого получаем:
    ($3000*50*12*3)+($3000*12*3)-($2000000+$50000*12*3)=$5400000+$108000-$3800000=$1708000
    Экономисческая эффективность очень приличная, следовательно имеет смысл внедрять.

    [1] – Patrick Thibodeau “In a symbolic shift, IBM’s India workforce likely exceeds U.S.” (http://www.computerworld.com/s/article/9234101/In_a_symbolic_shift_IBM_s_India_workforce_likely_exceeds_U.S.)

  8. Андрей, а вот с этим утверждением трудно согласиться:
    “Увеличение производительности труда персонала при переходе от 1С к SAP — 100% (вообще-то надо смотреть, какие модули внедряются и замерять время выполнения типовых операций в 1С и SAP, но здесь для простоты примем в качестве «среднего по больнице»).”

    Как это было получено? Кто сказал, что внедрение SAP привело к росту производительности персонала на 100%? Для того, чтобы это получить надо либо проводить оценку “по аналогии”, но опять же сама компания заказчик не имеет этих цифр и вынуждена полагаться на предоставляемую подрядчиком информацию, а это согласись все-таки могут быть “предвзятые” данные. С какой стати нам им доверять полностью? Как они это вычислили? Является ли это реальными значениями, или это просто PR?

    Второй вариант – оценка постфактум, то есть уже после внедрения проекта, но этот подход нам тоже не годится, мы то хотели что-то понимать заранее, принимая решение внедрять SAP или нет.

    Таким образом, на мой взгляд, здесь будет “тонкий” момент в твоих выкладках. То есть, если мы точно знаем какой рост производительности труда последует за внедрением SAP, то предложенная тобой схема работает, если этих данных у нас нет, то твой вариант сомнителен.

    Еще один важный “момент”. А кто сказал, что внедрение 1С или SAP или любой другой системы привело к росту прибыли компании? Фирма как-то работала без 1С. Сдавали бухгалтеры отчеты на бумаге, и все было нормально. Теперь планируется что-то внедрить – здорово, но где метрики, которые отражают рост производительности от внедрения системы автоматизации? Как их получить? Так что до тех пор пока у нас нет этих данных, мы просто оперируем непонятными цифрами.

  9. Уточнение к предыдущему расчёту:
    Среднее увеличение производительности труда заложено 10%, а не 100% (описка).
    Соответственно расчёт для второго варианта, при экономии 100 ставок будет таким:
    ($3000*100*12*3)+($3000*12*3)—($2000000+$50000*12*3)=$10800000+$108000-$3800000=$7108000
    То есть экономическая эффективность от перехода на SAP для 1000 человек в Москве ещё выше, следовательно имеет смысл внедрять.

    P.S. Для филиала той же компании в Ижевске (100 человек), где средняя зарплата $1000 получаем:
    1) В случае пилотного внедрения SAP в Ижевске:
    ($1000*10*12*3)+($3000*0,6*12*3)—($2000000*0,6+$50000*0,6*12*3)=$360000+$64800-$2280000=-$1855200
    Т.е. пилот “для экономии” в Ижевске делать не стоит, так как он принесёт чистый убыток.
    2) В случае внедрения SAP в Москве, а потом распространение клиентов в Ижевск (администраторы только в Москве):
    ($1000*10*12*3)+($3000*0,6*12*3)—($2000000*0,5*0,1+$50000*0,5*0,1*12*3)=$360000+$64800-$190000=$234800
    Т.е. получаем прямую экономическую выгоду, следовательно после внедрения в Москве, имеет смысл распространять проект далее, при сохранении централизованной модели администрирования.

  10. По поводу методики замера увеличения/уменьшения производительности после внедрения, есть следующий вариант:

    В технологическом центре вендора (отдельный привет любителям читать там семинары 🙂 ), либо на территории Подрядчика, разворачивается стенд с внедряемыми модулями SAP. Далее туда приглашается персонал Заказчика (по одному самому продвинутому человеку на каждую типовую операцию). Сотрудники Заказчика проходят краткий семинар по выполнению своих типовых операций и далее, непосредственно в присутствии представителей Подрядчика в качестве консультантов, садятся за рабочие места и поделывают свои типовые операции, замеряя время по секундомеру. После этого, сотрудники заказчика самостоятельно повторяют у себя в 1С теже операции, либо (что намного лучше) берут реальную накопленную статистику по процессам. Вычтя из второго времени первое, поделив на второе и умножив на 100% получаем значение увеличения производительности операций, которым может доверять Заказчик. Причём, ввиду отсутствия должного навыка на начальном этапе, это будет “оценка снизу”.

  11. А если там, например, проект по миграции с Windows Server 2008 на Windows Server 2012, тогда что?

  12. Уважаемый г-н Имя!

    В случае миграции AD с версии N на N+1 экономическая эффективность считается только на полном варианте.
    Если Вам это действительно надо, то подробности вы сможете узнать по адресу Andrey.V.Lavrov@gmail.com за $Xk (цена исследования зависит от количества персонала в компании и требуемой точности оценки). 🙂

  13. Уважаемый, Андрей!
    А разве itband не бесплатный ресурс, где просто можно поделиться знаниями и обсудить ИТ во всех его проявлениях ? 🙂

  14. Вы правы, itband.ru бесплатный ресурс, где можно поделиться знаниями, что я уже и сделал выше. Поскольку расчёт экономической эффективности миграции AD не является типовой задачей (полностью зависит от инфраструктуры компании Заказчика), то универсальной методики не существует (точнее она является бесконечной совокупностью методик учёта эффективности миграции AD для каждого конкретного инфраструктурного компонента). Ввиду этого, именно обсуждение экономической эффективности миграции AD это примерно тоже самое, что обсуждение экономической эффективности внедрения ITIL без привязки к конкретной компании. А в контексте конкретного Заказчика, посчитать экономическую эффективность миграции AD вполне себе можно, но это уже чистой воды консалтинг (нужно время на первичное обследование Заказчика и скурпулёзный подсчёт эффективности конкретно для него).

  15. Уважаемый Андрей,
    По сути приведенных Вами расчетов по методике с использование ФОТ могу возразить очень коротко: в условиях Вашего примера сказано, что “весь персонал компании дистрибутора считаем на 100% задействованным в увеличении выпуска продукции, причём в равной степени”, то есть сокращение численности персонала в принципе невозможно. Это остановит производственный цикл. То есть дальнейший расчет становится бессмысленным. При “эффективном” внедрении SAP, в данном случае, наше гипотетическое предприятие просто прекратит свое существование. Вообще, по опыту внедрений, сокращение сотрудников по результатам внедрения IT проектов явление исключительно редкое, наверное, оно где-то практикуется, но я с ним не встречался. Вспоминаем про компенсационный пакет для сотрудников, увольняемых по сокращению и падаем в обморок от цифры, особенно если сокращать придется много, щедрою рукою 🙂

  16. Уважаемый Alerter!

    Для того, чтобы сделать для Вас и остальных читателей суть изложенной мной методики расчёта экономической эффективности ИТ проекта более понятной, хочу пояснить смысл фразы “Также для упрощения весь персонал компании дистрибутора считаем на 100% задействованным в увеличении выпуска продукции, причём в равной степени”:
    1) Фраза означает, что на текущий момент “AS-IS” весь, без исключения, персонал принимает участие в выпуске продукции 40 часов в неделю, т.е. у нас нет тех, кто бьёт баклуши в ожидании распоряжения о планируемом повышении объёма производства на 10%, как это было в СССР, где объём выпуска планировался от достигнутого и, потому производственные мощности и персонал, директор собирал загодя, в ожидании нового “повышенного” плана. Здесь рассматривается рыночное предприятие, где все уже загружены по полной и, следовательно, для увеличения выпуска на 10%, без изменения технологии, необходимо увеличить на 10% персонал (и мощности, если по ним нет запаса, но мощности в данном случае не рассматриваем, т.к. не рассматриваем цену продукции, т.е. считаем ИТ проект чисто внутренним).
    2) В рассматриваемом примере, в качестве альтернативы варианту с необходимым увеличением числа персонала на 10%, без изменения технологии, предлагается внедрить новую технологию (на базе SAP), которая увеличит производительность труда на теже 10% (эта цифра выбрана исключительно для упрощения восприятия подсчёта, о том, как её считать на практике, смотри мои комментарии выше). Таким образом, внедрение новой технологии позволяет “сократить” ставки, которые неизбежно пришлось бы ввести без этого ИТ проекта для увеличения выпуска продукции. Таким образом, мы никого физически не увольняем, мы просто не принимаем на работу излишний персонал (никому никаких компенсаций в данном случае платить не требуется). Часть фразы “… причём в равной степени” позволяет нам при подсчёте избежать громоздкого учёта вклада каждого при реорганизации и тех же компенсаций, о которых вы упомянули.

    P.S. Вообще говоря, расчёт экономического обоснования ИТ проекта для не вырожденного примера, как здесь, это большой труд, который выливается в солидный документ (у консалтинговых компаний из большой четвёрки он будет от 100 листов, я, с учётом “востребованности” тщательного подсчёта экономической эффективности, обычно умещался в 10-50 листов). В любом случае, в 20 строк комментария сделать разбор реального примера не получится (да и нет желания разбирать частный случай). Как сейчас помню одно моё выступление на семинаре, где нельзя было называть имя Заказчика, все разделы начинались фразой “В компании, являющейся крупнейшим оператором связи в России …” (если пример реальный, то трудно не догадаться).

  17. Уважаемый г-н Лавров!
    Чуть-чуть замечаний.
    1. Планирование производительности труда в Вашем примере – это как раз иллюстрация принципов плановой экономики СССР. Злобный буржуй-капиталист интересуется только оборотом (выручкой), на что я и опирался в своем примере. Оборот первичен, а на производительность по большому счету ему плевать, лишь бы достигался необходимый план по выручке. Спросите любого собственника среднего бизнеса, он подтвердит мои слова. Точнее, собственника интересует конечно же прибыль, но это слишком сложное понятие, чтобы обсуждать его в нефинансовом кругу. Поэтому пусть будет выручка/производительность, это всего лишь мелкая неточность. Б-г с ней.
    2. Вторая часть гораздо интереснее. Внедрение проекта ERP подразумевает две обязательных вещи: реинжиниринг бизнес-процессов из ASIS в TOBE и внедрение собственно компьютерной системы. Но! Кто сказал, что реинжиниринг процессов напрямую связан с внедрением IT решения? Реинжиниринг – это активность Операционного Менеджмента, а IT проект – это следствие. Производительность труда повысится за счет того, что SAP будет намного быстрее обрабатывать намного больше транзакций? Чушь! Выигрыш будет именно за счет устранения избыточных активностей в самих бизнес процессах. Цепочки действий сократятся и бизнес максимально приблизится к модели Майкла Портера. Раньше кладовщик делал 15 движений по складу, чтоб отгрузить товар, но за счет внедрения батчей и FIFO он делает 7 движений. Рабочий таскал детальки от станка к станку хаотично, теперь станки переставлены в конвейер и детальки таскать не надо, достаточно взять, обработать, передать дальше. Логистик не знал, где находятся машины, но за счет внедрения GPS или аутсорсинга транспортной компании, теперь точно известно положение фуры. И т.д. Что мы имеем от этого утверждения? Что в общем-то можно позвать хороших, добрых и дорогих SAPовских консалтеров, чтоб они на нашем предприятии нарисовали AS IS и TOBE , заплатить им за эту работу и выгнать их взашей, а решение применить на той же 1С конфигурации. И производительность поднимем и на внедрении сэкономим столько, что собственник будет в истерике валяться у нас в ногах и вопить «Аллилуйя!». Ну это я утрирую, скорее-то всего никто ничего не поймет и даже премию не выпишут  Какова роль IT системы в этом примере? Да очень трудно сказать теперь. Если отделить реинжиниринг от IT получается, что IT в данном случае исполняет роль оболочки к движку реинжиниринга. Можно купить оболочку лицензионную за пару миллионов долларов, а можно и не заморачиваться – старую перенастроить. Все зависит от таланта директора по развитию.
    И это был очевидный пример, где реинжиниринг процессов напрямую приводил к увеличению производительности труда. Другие частные инфраструктурные проекты типа миграции ОС, внедрение АД, средств безопасности еще менее очевидны. Есть насущная необходимость, когда к техническому перевооружению нас толкает вендор. Типа: «больше мы не будем обновлять наш софт никогда, извините. Делайте, что хотите или переходите на нашу следующую версию за деньги.»

  18. Уважаемый Alerter!

    В ответ на Ваши замечания, считаю необходимым отметить следующее:
    1) Вы в корне не верно поняли суть приведённой мной методики расчёта эфективности. Принципы плановой экономики СССР не имеют к ней никакого отношения, и были упомянуты мной в комментарии, как раз в качестве антипримера (Советсткие директора набирали штат и мощности с огромным запасом и, при этом, занижали резервы в статистической отчётности, чтобы, когда им на голову свалится очередной “повышенный” план без обеспечения ресурсами, они могли спокойно “изыскать” резервы и “героически” его выполнить, получив за это должности, награды, премии и т.п. При таком подходе автоматизация вообще не нужна, т.к. есть постоянные непроизводительные потери.). В предложенной мной методике расчёта экономической эффективности, напротив, приведена схема расчёта эффективности через прибыль (для внутреннего проекта доля в прибыли равна величине экономии затрат). Термин “выручка”, я нигде в своей методике не использовал, так как она не имеет отношения к расчёту экономической эффективности (это понятие использовали Вы в своём примере и комментариях). Если для Вас оперирование понятием прибыль сслишком сложно, то действительно не стоит здесь далее что-либо обсуждать. Мне, с моими знаниями экономики, бухгалтерского учёта, сертификациями по ITIL, опытом внедрения ERP, а также опытом работы с платформами 1C, SAP и т.д., вот совершенно не сложно обсуждать подобные вещи, поверьте.
    2) Вы вполне правильно изложили базовые понятия реинжиниринга бизнес процессов. Действительно, в реальной жизни, необходимо учитывать все операции полностью, но ввиду того, что каждый шаг бизнес процесса на современном предприятии заканчивается отчётным документом (внесением данных в ERP), то оценка сокращения количества операций по ERP даёт хороший результат (также никто не мешает Вам встать на складе с секундомером и замерить время операций вживую “AS-IS” и с использованием удалённого доступа к тестовому стенду с макетом системы “TO-BE” от потенциального Подрядчика проекта). Только, вот какое отношение это имело к Вашему микро примеру о предприятии, желающем увеличить выпуск неизвестно чего, неизвестно как на 10% (я предположил, что Вы имели ввиду увеличение выручки на 10% не за счёт банального увеличения цены на 10%, а за счёт увеличения выпуска продукции на 10%, иначе тогда зачем что-то вообще менять)? Ваш пример, не снабжённый необходимыми исходными данными, я дополнил значениями основных величин, без которых расчёт экономической эффективности, даже в простейшей форме, не возможен. Вся остальная модель бизнес процессов на абстрактном предприятии из примера была сознательно упрощена, чтобы не выполнять целый проект ради иллюстрации методики в одном комментарии.
    И, наконец, Вы правы, что 1С и SAP это просто инструменты и при большом желании ERP можно реализовать на 1C (также верно, что всю систему можно написать вообще с нуля). Только вот вопрос в том, сколько будет стоить довести 1С до уровня SAP (особенно, если рассматривать модули макро анализа 🙂 ). Понятно, что цена доработки зависит от требуемого функционала ERP. Если штатные конфигурации 1С покрывали требуемый функционал в Вашем примере, то зачем тогда Вы предложили менять его на SAP? В своём расчёте я исходил из того, что согласно Вашему примеру переход на SAP является более дешёвым вариантом автоматизации бизнес процессов, черем доработка 1С с последующим сопровождением (Я использовал Ваши цифры!).
    В заключение:
    Проекты по миграции ОС, миграции AD, средств безопасности также очевидны, хотя и более сложны в учёте, так как затрагивают всю инфраструктуру.
    Переход на новую версию продукта должен быть ВСЕГДА экономически обоснован.
    Переход на новую версию, только потому, что она вышла – экономически нецелесообразен, так как априори не подразумевает изменение бизнес процессов, но включает затраты на переход и обслуживание. Если очень хочется обосновать переход на Windows 8, например, потому, что она имеет встроенную поддержку TPM 2.0 и, соответсвенно, позволяет очень хорошо защитить информацию на мобильных устройствах, то Вам придёться доказать, что эта информация стоит больше, чем обновление аппаратной части (обязательный мультитач дисплей) и программной части всего клиентского парка.

  19. Ваш комментарий