Поможем в ✍️ написании учебной работы

Имя

Поможем с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой

Выберите тип работыЧасть дипломаДипломная работаКурсовая работаКонтрольная работаРешение задачРефератНаучно - исследовательская работаОтчет по практикеОтветы на билетыТест/экзамен onlineМонографияЭссеДокладКомпьютерный набор текстаКомпьютерный чертежРецензияПереводРепетиторБизнес-планКонспектыПроверка качестваЭкзамен на сайтеАспирантский рефератМагистерская работаНаучная статьяНаучный трудТехническая редакция текстаЧертеж от рукиДиаграммы, таблицыПрезентация к защитеТезисный планРечь к дипломуДоработка заказа клиентаОтзыв на дипломПубликация статьи в ВАКПубликация статьи в ScopusДипломная работа MBAПовышение оригинальностиКопирайтингДругое

Нажимая кнопку "Продолжить", я принимаю политику конфиденциальности

 

Проект внедрения системы класса ERP, рассмотренный в предыдущих темах, — это самый сложный тип проектов развития информацион­ных систем.

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

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

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

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

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

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

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

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

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

Таким образом, вышеизложенные принципы ведения проектов внед­рения ERP-систем оказываются применимыми и к проектам меньшего масштаба.

 

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

                                                                   Таблица 8.3 Содержание этапов проектов по видам ИТ-проектов.

Вид проекта

Подготовка

Технический проект

Реализация

Заключительная подготовка

Снижение ССВ

Менеджер.

Контроль качества

Спецификация. Изменения

Установка оборудования и ПО. Предварительное тестирование

Тестирование доработок. Обучение

Инфраструктурный проект

Проектная группа. Управление изменениями. Контроль качества

Технический проект

Установка оборудования. Настройка ПО. Тестирование

Тестирование доработок. Обучение

Инфраструктурная проблема

Проектная группа. Управление изменениями. Контроль качества

Технический проект

Установка оборудования. Настройка ПО. Тестирование

Тестирование доработок. Обучение

АСУ ТП

Проектная группа. Управление изменениями. Контроль качества

Технический проект

Установка оборудования. Настройка ПО. Тестирование

Тестирование доработок. Обучение

Предметная область

Менеджер. Контроль качества

Спецификация. Требования к инфраструктуре

Установка оборудования и ПО. Предварительно тестирование

Тестирование доработок. Обучение

Финансы-внедрение

Менеджер. Контроль качества

Спецификация. Требования к инфраструктуре

Установка оборудование и ПО. Предварительное тестирование.

Тестирование доработок. Обучение

Финансы-разработка

Проектная группа. Управление изменениями. Контроль качества

Концептуальный проект

Разработка ПО. Тестирование

Тестирование доработок. Обучение

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

Методики ведения крупных ИТ-проектов, такие как ASAP, примени­мы и к проектам меньшего масштаба. Прежде всего, заслуживает вни­мания принятое в этих методиках деление проекта на этапы и работы, выполняемые в рамках данных этапов. Далее, для любого проекта край­не важны принцип документирования результатов работ и утверждение документов конечным пользователем. Наконец, полезен принцип учета затрат по модели ФСА и учета рисков по методу дерева сценариев.

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

 

 

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

· утверждения организационной структуры проекта с четким распреде­лением ролей уже на первом этапе проекта;

· установления с начала проекта согласованных процедур управления изменениями и контроля качества;

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

· фиксирования требований пользователей к системе в согласованном пользователями и разработчиками концептуальном проекте: «тре­бование пользователя есть то, что записано в концептуальном про­екте»;

· сведения к разумному минимуму собственных разработок в проекте;

· многоступенчатой системы тестирования произведенных настроек и раз­работок с целью обеспечения соответствия фактических настроек сис­темы концептуальному проекту.

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

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

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

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

Цель модели — представить формализованное описание денежных потоков, связанных с ИТ-проектом. В качестве средств формирования такого денежного потока использованы четыре учетные модели, широко применяемые в современном экономическом анализе: ССВ (совокупная стоимость владения), ФСА/ФСУ (функционально-стоимостной анализ/ функционально-стоимостное управление), КПР (ключевые показатели результативности), дерево сценариев.

 

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

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

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

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

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

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

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

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

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

 

 

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

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