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

Первый существенный в данном вопросе момент — дискретность обе­их составляющих денежного потока: как денежных сумм Сt, так и веро­ятностей р_t. Причина первого явления — в существовании графика пла­тежей, исходя из которого каждый платеж привязан к определенной дате; причина второго — в том, что руководство предприятия контроли­рует проект в определенных контрольных точках, для каждой из кото­рых предусматривается некоторый осязаемый и доступный для контроля результат — проект, утвержденный прототип или работающая и протес­тированная система. За пределами этих контрольных точек решения от­носительно хода проекта, как правило, не принимаются. Исключением может стать ситуация явных признаков неудачи проекта, однако она не нуждается в специальных методах экономической оценки. Другое воз­можное исключение — остановка проекта по политическим соображени­ям, которая вследствие своего неформального характера также остается за пределами нашего анализа.

Вернемся к уравнению (7.1). Денежный поток затрат на проект ха­рактеризуется двумя векторами: суммами затрат С и вероятностями их наступления р. По данному денежному потоку рассчитывается чистая приведенная стоимость с коэффициентом дисконтирования d, которая входит как одно из слагаемых в уравнение финансового результата про­екта. Предполагается, что величины и моменты затрат на проект предо­пределены и вероятностным законам подчиняется только продолжение проекта до момента времени t. Под вероятностью р₍ наступления данного расхода С, как элемента денежного потока понимается вероятность того, что проект продолжается от момента времени t-1 до момента времени t. В свете сказанного рассмотрим уравнение (7.1) исходя из предположе­ния о независимости наступления затрат С1...С n’. Уравнение (7.1) пре­образуется к виду:

                                           ,                                  (8.38)

где t = l...n — периоды времени, в которые происходят инвестицион­ные затраты;

d — коэффициент дисконтирования.        

                                      .                                 (8.39)

В случае зависимых С1...С_n в уравнение (8.39) добавляются члены, описывающие вероятности (Сⁿ _j |С_j), которые усложняют формулу, но не меняют ее принципиально. В графическом виде слагаемые уравнения (8.39) приведены на рис. 8.5.

Главный вывод из уравнений (8.38), (8.39) подтверждает интуитивное предположение: вероятности завершающих шагов проекта влияют на общий финансовый результат гораздо сильнее, чем вероятности шагов начальных. Как следствие, организация проекта должна обеспечивать тем большую надежность, чем ближе к завершению находится проект.

Рис. 8.5 Денежный поток по фазам проекта внедрения.

Итак, от чего зависит вероятность отказа от проекта или его полной остановки? Ответ также интуитивно очевиден. Руководство предприятия может распорядиться закрыть или заморозить проект, если возникают сомнения в его успешном завершении в оговоренные сроки. Основани­ем для этого могут стать невыполнение установленных сроков и бюдже­та, сомнения в качестве проведенных работ либо непредвиденные изме­нения объема проекта.

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

· низкий уровень планирования и организации проекта. В этом случае состав работ на этапе оценки фактически неизвестен, то есть сроки и бюджет не соответствуют реальному объему работ;

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

· слабое ресурсное обеспечение работ со стороны, как предприятия, так и внешнего консультанта. Речь может идти о низкой квалификации со­трудников, привлеченных к проекту, недостаточном их количестве, не­хватке иных ресурсов (помещений и т.д.). Эти проблемы могут быть связаны как со слабым организационным обеспечением, так и с не­удачным выбором консультанта;

· отсутствие регламента контроля качества работ и внесения измене­ний в объем проекта. Хотя эти моменты можно отнести к п. 1, 2, их важность заставляет оговорить их отдельно. Экономическое обосно­вание проекта, его план и бюджет строятся исходя из предположений об объеме проекта. Поэтому любое существенное его изменение вле­чет за собой пересмотр всех трех документов, что означает не толь­ко ощутимые расходы на проект и управление им, но и аннулирование ранее сделанных расходов. В свою очередь, зафиксированный объем работ должен быть подкреплен процедурами контроля качества, обес­печивающими соответствие объема и качества фактически выполнен­ных работ требованиям заказчиков проекта.

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

Подобным компромиссом представляется допущение изменений в про­ект лишь при выполнении одного из трех условий:

· изменение обусловлено уточнением границ бизнес-процессов. Ранее было показано, что сложные финансово-экономические системы, пре­жде всего системы класса MRP II/ERP и родственные им, основаны на определенных стандартах бизнес-процессов и эффективны лишь при сколько-нибудь целостной реализации последних. Поэтому в ходе выполнения проекта, например на стадии концептуального проекти­рования, могут быть уточнены организационные и функциональные границы бизнес-процессов, подлежащих автоматизации. Приведем пример такого изменения в проекте оптимизации управления запаса­ми (см. тему 7). Объем проекта был определен исходя из обеспечения сырьем и комплектующими основного производства. При выполнении работ были обнаружены вспомогательные производства, снабжаемые в рамках единого процесса закупок и имеющие общие склады с основ­ным производством. Это может сделать целесообразным расширение объема проекта за счет вспомогательных производств;

· изменение обусловлено невозможностью эффективного решения той или иной проблемы в установленные планом проекта сроки. Продол­жим рассмотрение предыдущего примера. Допустим, было принято решение расширить объем проекта. Однако при выполнении работ было обнаружено, что потребности вспомогательного производства не могут быть определены в сроки, требуемые внедряемой систе­мой (например, возможны крупные объемы закупок, не включенные в ежедневный график заранее). Тогда следует отложить автоматиза­цию закупок вспомогательного производства вплоть до того момен­та, когда планирование закупок последнего будет синхронизировано с планированием основного производства. Если такая синхрониза­ция невозможна в сроки, предусмотренные планом проекта, автома­тизацию закупок вспомогательного производства следует отложить и предусмотреть в общем плане закупок резервы под закупки вспомо­гательного производства;

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

Важный механизм, ограничивающий внесение в проект нежелатель­ных изменений, — управление ожиданиями. Оно направлено на создание благоприятного отношения к проекту при сведении к минимуму несбыв­шихся ожиданий пользователей.

К основным принципам управления ожиданиями относятся:

· приоретизация требований пользователей — проектная команда со­вместно с бизнес-пользователями присваивает требованиям приори­теты;

· сосредоточение на приоритетных требованиях при сокращении или полном отказе от остальных — менее приоритетные требования выполняются посредством доработок после сдачи сервисов в эксплуатацию;

· балансирование требований и ресурсов — проектная команда дает ре­сурсную оценку требований пользователей, отсутствие ресурсов упро­щает отклонение требований;

· явное формулирование рисков, вытекающих из превышения ресурс­ных возможностей.

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

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

В заключение отметим, что при анализе затрат и рисков, связанных с проектом, объем проекта и связанный с ним денежный поток дохо­дов не должны рассматриваться как жестко заданные величины. На деле слагаемое, связанное с доходом, определяется как собственно денеж­ным потоком доходов, так и вероятностью отмены проекта так что обе величины должны оптимизироваться совместно. На практике задача упрощается ограниченностью множества проектов — речь всегда идет не о континууме вариантов, а об их конечном числе. Это позволяет сравнивать варианты на основании уравнения, дополнив предварительно данные по денежным потокам экспертными оценками вероятностей. Для повышения надежности таких расчетов может быть применен сценарный подход в виде оценки сценария развития проекта по плану и с различными сценариями отставания от графика. Подробно раз­витие проекта будет рассмотрено в следующей теме.

Экономический анализ проекта внедрения определяет два из трех ос­новных параметров такого проекта: денежного потока затрат на внедре­ние и вероятности успешного завершения работы в целом. Расчет зна­чительно упрощается в предположении об использовании современных методов управления проектом: решение об остановке или заморажива­нии проекта принимается по завершении определенных фаз проекта на основании представленных результатов. В этих предположениях иско­мые величины были получены.

Как средства минимизации затрат на проект внедрения рассмотрены стандартные методики ведения проекта: ASAP фирмы SAP и Ascendant. Выбор той или иной методики непринципиален, однако в рамках одного проекта необходимо твердо следовать изначально выбранной методике. Минимизация затрат требует, кроме этого, контроля соответствия объ­ема проекта выделенным ресурсам и сведения к минимуму риска оста­новки проекта, особенно на его завершающих стадиях. Основные сред­ства достижения таких результатов — ограничения внесения изменений в проект и управление ожиданиями бизнес-пользователей.

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