Размещено на http://www.Allbest.ru/

Размещено на http://www.Allbest.ru/

Федеральное государственное автономное образовательное учреждение высшего образования

Национальный исследовательский университет

Высшая школа экономики

Факультет бизнеса и менеджмента

Направление подготовки 38.03.05 Бизнес-информатика

Образовательная программа «Бизнес-информатика»

Выпускная квалификационная работа - бакалаврская работа

Тема:

Применение информационных систем в управлении проектом на примере компании «КРОК»

Студент Субботин Дмитрий

Научный руководитель

доцент, к.т.н. С.М. Ямпольский

Москва, 2017



Оглавление

• Введение
• Глава 1. Теоретические предпосылки исследования
• 1.1 Анализ успешных IT-проектов
• 1.2 Возможные причины невыполнения проектов
• 1.3 Инструментальные методы достижения цели и их обоснование
• 1.3.1 Обоснование выбора инструментального средства для описания процесса управления проектами
• 1.3.2 Метод поиска возможных нововведений
• 1.3.3 Практическая значимость предложенного подхода
• 1.4 Постановка задачи
• Глава 2. Текущий подход к управлению проектами в компании КРОК
• 2.1 Информационные системы и управление проектами
• 2.2 Информационные системы, участвующие в управлении проектами компании КРОК
• 2.3 Существующая функциональная модель процесса управления проектами
• 2.4 Обмен данных между системами
• 2.4.1 Общие сведения
• 2.4.2 Синхронизация информационных систем
• 2.4.3 Интеграция информационных систем
• Глава 3. Предлагаемые изменения в подход к управлению проектами
• 3.1 Анализ текущего процесса
• 3.2 Описание изменений для внедрения
• 3.2.1 Предлагаемые изменения
• 3.2.2 План внедрения изменений
• 3.3 Ожидаемый экономический эффект
• 3.4 Оценка эффективности предлагаемых изменений
• 3.4.1 Алгоритм расчета эффективности
• 3.4.2 Пример применения предложенного алгоритма
• Заключение
• Список литературы



Введение

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

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

Объектом исследования данной работы является деятельность компании ЗАО «КРОК инкорпорейтед», которая является одним из лидеров российского ИТ-рынка.

Предметом исследования является процесс получения агрегированной информации от совокупности взаимосвязанных информационных систем, объединенных в единое информационное пространство.

Для достижения поставленной цели в ходе исследования необходимо решить следующие задачи:

1. Описать функциональный процесс управления проектами в компании ЗАО «КРОК инкорпорейтед» с точки зрения применяемых информационных систем;

2. Разработать методику для повышения эффективности управления проектами.

Данная работа состоит основной части, которая подразделяется на три главы, введение, заключение и список используемой литературы.

Первая глава содержит информацию о предпосылках исследования, его содержании и границах.

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

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

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



Глава 1. Теоретические предпосылки исследования

1.1 Анализ успешных IT-проектов

В 2012 году Бент Фливбьерг и Александер Будзиер провели исследование данных об IT-проектах, целью которого было получить статистику об успешности проектов в целом, а также по отдельным отраслям, и выявить основные причины, по которым проект мог оказаться незавершенным и потерпеть крах. В ходе исследования были проанализированы данные о более чем 1300 IT-проектах, большинство из которых были проведены в США. Оказалось, что подавляющее большинство проектов были успешными, а их фактический бюджет не превышал запланированный более, чем на 25% [1].

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

Другой крайностью отклонений от планируемых показателей проекта было сокращение бюджета заказчиком. Почти половина проектов, связанных с государственным сектором, лишилась 75% финансирования. Очевидно, далеко не все проекты были закончены в таких условиях, а те, что все же завершились, вынуждены были идти на сокращение объемов работ или их качества.

Данная статистика приведена для США, но подобные тренды прослеживаются и в России [2], поэтому описываемая проблема актуальна и для нашей страны. Значительная часть от всех проектов, проводимых компанией ЗАО «КРОК инкорпорейтед», относится к государственному сектору, что несет за собой риск столкнуться с проектом, который впоследствии окажется черным лебедем или же лишится крупной доли финансирования.

1.2 Возможные причины невыполнения проектов

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

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

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

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

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

Вторая частая причина - оптимистическое предубеждение [4]. Изначально этим термином называли только отношение человека к собственным рискам по сравнению с рисками других людей, а также его способностям на фоне умений остальных. Предубеждение заключается в том, что люди склонны оценивать себя выше среднестатистического человека, а связанные с собой риски, наоборот, недооценивать. Например, согласно опросу, на одной фабрике, 42% инженеров были убеждены, что входят в 5% наиболее квалифицированных инженеров компании [5]. Со временем этот термин стал использоваться и в деловом общении. В отношении управления проектами оптимистическое предубеждение означает сознательное или несознательное игнорирование некоторых рисков проекта (например, могут оцениваться только внутренние риски компании и не рассматриваться риски, связанные с компанией-заказчиком). Халатное отношение к подсчету рисковых ситуаций и убежденность в невозможности нежелательного сценария может привести к тому, что в момент наступления негативного развития событий проектная команда оказывается неготовой к ней и не может оперативно отреагировать. Как следствие, падает эффективность проекта, растет его стоимость, а возможно ставится под вопрос успешность всего проекта.

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

1.3 Инструментальные методы достижения цели и их обоснование

1.3.1 Обоснование выбора инструментального средства для описания процесса управления проектами

Для описания процесса управления проектами AS-IS выбран вариант построение модели процесса с помощью методологии ARIS (Architecture of Integrated Information Systems). Наиболее подходящим типом модели для решения данной задачи будет eEPC-модель, построенная в виде блок-схемы [6]. Выбранный вариант модели позволит продемонстрировать, а в дальнейшем провести анализ, основываясь не только на последовательности функций и событий, но и с учетом проектной роли исполнителя и используемой информационной системы. Другим важным преимуществом является тот факт, что методология ARISшироко распространена и служит одним из наиболее востребованных решений для описания процессов. Таким образом, построенная модель может быть использована не только в данной работе, но и в возможных планах ЗАО «КРОК инкорпорейтед» по изменению внутренней инфраструктуры компании. Модель будет сопровождаться текстовым описанием процесса для более подробного описания, а также функций, которые не вошли в процесс управления проектами, но являются важными с точки зрения работы информационных систем и на которые следует обратить внимание при разработке предложений по совершенствованию инфраструктуры.

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

1.3.2 Метод поиска возможных нововведений

Для поиска возможных нововведений будет применен подход DMAIC (Define, Measure, Analyse, Improve, Control). Этот подход нацелен на оптимизацию и повышение эффективности в существующих бизнес-процессах [7]. Суть подхода состоит в последовательном выполнении пяти шагов [8]:

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

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

3. Анализ - поиск основных источников проблем и возможностей для совершенствования. На этом этапе происходит осмысление полученных на предыдущем шаге данных, производится поиск коренных причин ошибок в процессе.

4. Совершенствование - разработка и внедрение улучшений в текущий процесс. Здесь описываются и применяются изменения, которые должны быть внесены в процесс, а также доказывается практическая значимость внедряемых изменений.

5. Контроль - разработка и применение системы отслеживания отклонений процесса от плана. Цель данного шага - убедиться, что внедренные изменения действительно пошли на пользу процессу, и его эффективность повысилась.

Изначально метод был разработан для использования на промышленном предприятии, но в дальнейшем он был успешно применен и для совершенствования бизнес-процессов в компании, занимающейся выпуском программного обеспечения [9], что совпадает с одним основных из направлений деятельности ЗАО «КРОК инкорпорейтед». Поэтому метод DMAIC может быть использован для решения задачи данной работы.

Шаг «Определение» будет описан в главе 1 данной работы, раздел «Постановка задачи». Шаг «Измерение» будет выполнен в главе 2 данной работы. Результат выполнения шагов «Анализ», «Совершенствование» и «Контроль» будет описан в главе 3. Учитывая тот факт, что ЗАО «КРОК инкорпорейтед» является крупной компанией на российском ИТ-рынке, переработать процесс управления проектами будет непросто, а время внедрения таких переработок может затянуться на несколько лет. Руководствуясь этим фактом и определенными границами работы, в ходе выполнения шага «Совершенствование» будут описаны возможные изменения процесса, но его внедрение в рамках данной работы не предполагается. Следующий шаг - «Контроль» - также будет представлен только в виде описания критериев, на которые следует обратить внимание при контроле эффективности внедренных изменений в том случае, если шаг «Совершенствование» будет в дальнейшем доведен до конца, а изменения воплощены в жизнь.

1.3.3 Практическая значимость предложенного подхода

Предлагаемый подход позволяет достичь гибкости в среднесрочной перспективе, если предлагаемые изменения в инфраструктуру ЗАО «КРОК инкорпорейтед» будут одобрены руководством компании и послужат стимулом для переосмысления текущей ситуации. Модель ARIS понятна без дополнительных пояснений благодаря своей распространенности - существует множество учебников по методологии ARIS, а значит разобраться с моделью сможет любой сотрудник компании, привлечение дополнительных специалистов не потребуется, что позволит сэкономить бюджет. Текстовое описание позволит понять модель и сам процесс более детально и поможет акцентировать внимание на наиболее важных функциях процесса. Метод DMAIC имеет четкую структуру и логику последовательности шагов. При реализации предлагаемых изменений будет достаточно подробно ознакомиться с шагами «Совершенствование» и «Контроль». Но при этом метод позволяет получить представление о том, почему были сделаны именно такие предложения, для этого достаточно ознакомиться с предыдущими шагами метода.

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

1.4 Постановка задачи

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

Проблема данной работы: компания ЗАО «КРОК инкорпорейтед» не минимизирует риски и издержки, связанные с поддержкой управления проектами из-за неэффективной работы информационных систем в этой области.

Для решения этой проблемы в компании ЗАО «КРОК инкорпорейтед» необходимо решить следующие задачи:

1. Описать функциональный процесс управления проектами компании с использованием методологии ARIS с указанием применяемых информационных систем;

2. Проанализировать текущий процесс управления проектами и выявить его слабые стороны;

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

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

5. Предложить систему расчета эффективности внедренных изменений для потенциального анализа после внедрения.



Глава 2. Текущий подход к управлению проектами в компании КРОК

2.1 Информационные системы и управление проектами

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

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

· Базовая поддержка управления проектами;

· Управление знаниями;

· Управление процессом;

· Поддержка общения и совместной работы.

Несмотря на большое разнообразие на рынке программного обеспечения, ни одна система не способна работать одновременно во всех четырех областях и покрывать все необходимые бизнесу функции [10]. Таким образом, для эффективного управления проектами компании выстраивают сложную инфраструктуру из нескольких информационных систем, которые взаимодействуют между собой, передавая друг другу данные и обмениваясь нотификациями. Каждая из информационных систем в этой инфраструктуре отвечает за свою область и выполняет ограниченный круг функций, как правило одна информационная система относится к одной из четырех областей, перечисленных выше. Бизнес, который стремится к преимуществу перед своими конкурентами, должен следить за эффективностью всей инфраструктуры и своевременно обновлять отдельные ее компоненты, а возможно и переосмыслять всю логику поддержки управления проектами.

2.2 Информационные системы, участвующие в управлении проектами компании КРОК

Компания ЗАО «КРОК инкорпорейтед» сформировала собственный процесс управления проектами и инфраструктуру, состоящую из ряда информационных систем, объединенных между собой. Каждая из них предназначена для выполнения своей функции. Нацеленная на лидерство на российском рынке, компания стремится поддерживать актуальность всех систем, поэтому каждая из них постоянно дорабатывается и совершенствуется, системы обрастают новыми модулями и позволяют выполнять все новые задачи. На данный момент в процессе управления проектами участвуют следующие системы:

· Microsoft CRM - CRM-система компании, в которой хранятся данные о контрагентах, с которыми компания ведет деятельность, их реквизиты и сделки с ними;

· CA Clarity - система, целью которой является планирование календарных работ проекта, а также отслеживание трудозатрат сотрудников компании по задачам и оптимизации их загрузки на проекте;

· К2 - система для согласования деятельности сотрудников с ответственными лицами компании;

· Финансовый калькулятор - система для планирования денежных потоков проекта: расходов и доходов в различные этапы проекта (собственная разработка);

· 1С ERP - ERP-система компании, в которой хранятся договоры с контрагентами, а также учитываются фактические закупки и продажи, движение денежных средств;

· Targit BI - BI-система компании, в которую выгружаются данные по проекту и происходит план-факторный анализ, а также анализируются изменения показателей по проектам в целом;

· OpenText Documentum D2 - платформа хранения и управления корпоративными документами;

· Atlassian Jira - система организации взаимодействия работы сотрудников проектных команд между собой;

· Jive - система, предназначенная для управления знаниями компании в целом и отдельно по проектам;

· Система управления контрольными точками - система, созданная для заведения контрольных точек проекта, их согласования и утверждения (собственная разработка).

Перечисленные информационные системы участвуют во всех проектах компании ЗАО «КРОК инкорпорейтед». В зависимости от департамента и проекта в процесс могут включаться и другие системы, предназначенные для решения более специфических задач.

2.3 Существующая функциональная модель процесса управления проектами

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

Типовой процесс управления проектами делится на пять стадий в соответствии со стадиями самого проекта:

1. Тендер

Правительство или другая компания объявляет тендер на проведение проекта. В случае, если компания заинтересована в проекте, то менеджер потенциального проекта делает коммерческое предложение. После этого сотрудник компании, который входит в проектную команду, заносит основную информацию о клиенте в Microsoft CRM, статус клиента - «Потенциальный». Здесь же заводится возможная сделка с клиентом, на данном этапе согласование сделки не требуется. После создания возможной сделки назначается директор клиента - куратор будущего проекта со стороны ЗАО «КРОК инкорпорейтед», который будет следить за ходом работ по проекту. Как правило, директор клиента курирует сразу несколько проектов, клиенты которых работают в одной области.

Функциональная модель процесса управления проектом на стадии тендера представлена на рисунке 1.

Рисунок 1. Функциональная модель проекта, тендер

2. Пресейл

В случае, если компания выигрывает первый этап тендера, начинается следующий этап - пресейл. Первым шагом на данном этапе является подготовка технического задания сотрудником из проектной команды. Затем создается сущность «Активность» в системе CA Clarity, которая отвечает за хранение информации по проекту и требует согласования от директора клиента в системе K2. После согласования активности в системе Финансовый калькулятор заводятся плановые данные по затратам на пресейл (на этом этапе предполагаются только прямые затраты на проект без наличия дохода). При наличии согласования и плановых данных активность в CA Clarity трансформируется и становится активной.

Функциональная модель процесса управления проектом на стадии тендера представлена на рисунке 2.

Рисунок 2. Функциональная модель проекта, пресейл

3. Старт проекта

Если пресейл прошел успешно и заказчик доволен результатами, то данные о клиенте дополняются в Microsoft CRM, статус сменяется на «Фактический». Изменения контрагента согласуются К2 директором клиента. Затем подписывается договор между заказчиком и ЗАО «КРОК инкорпорейтед». Данные о договоре сотрудник проектной команды записывает в 1С ERP, после чего в Финансовом калькуляторе он заполняет плановые данные договора - информацию о доходах и расходах на каждом этапе выполнения проекта, запускается согласование договора. Он должен получить одобрение от экономиста, который уточняет рентабельность проекта, и юриста, который проверяет корректность юридических формулировок, а также наличие потенциальных рисков. После согласования договора сотрудником проектной команды запускается старт проекта в К2, который предназначен для официального завершения работ по выверке сделки с клиентом и начала проектных работ. Процесс старта проекта автоматически проставляет электронную цифровую подпись на договоре. Наличие ЭЦП позволяет менеджеру проекта внести календарный план работ проекта в CA Clarity с указанием сроков каждого направления работ и трудозатрат на него. Заполнение плана возможно как непосредственно в системе, так и импорт его из Microsoft Project - распространенного решения для составления плана проекта.

Функциональная модель процесса управления проектом на стадии старта проекта представлена на рисунке 3.

4. Проект

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



Рисунок 3. Функциональная модель проекта, согласование и старт проекта

Запись о трудозатратах делается в системе CA Clarity. В этой же системе менеджер проводит план-факторный анализ, сравнивая затраченные человеко-часы на каждую задачу и, возможно, корректируя план проекта, чтобы тот был более эффективен (например, переносит предполагаемые трудозатраты с одной задачи на другую). Подобный анализ проводится и для денежных потоков. В системе Targit BI менеджер видит понесенные затраты и полученные от клиента денежные переводы (данные в систему загружаются из 1С ERP ежедневно) и делает выводы о ходе проекта. Еще одним методом контроля являются контрольные точки. В начале проекта задаются даты контрольных точек и условия их прохождения. Условия могут быть обязательными или желательными. В момент наступления даты контрольной точки менеджер проекта и директор департамента, в котором проводится проект, выносят свои решения о том, пройдена контрольная точка или нет. Контрольная точка не может быть пройдена, если хотя бы одно из обязательных условий не было выполнено. В дальнейшем по статусу контрольных точек судят об эффективности проекта и проектной команды.

Функциональная модель процесса управления проектом на стадии старта проекта представлена на рисунке 4.

Рисунок 4. Функциональная модель проекта, активная фаза проекта

5. Закрытие проекта

После окончания работ по проекту клиент выносит решение о закрытии проекта, если он удовлетворен результатом. После этого менеджер проекта переводит проект в статус «Закрыт» в системе CA Clarity. Во время закрытия проекта происходит проверка на наличие товарных остатков на складах компании, которые зарезервированы под данный проект.

Функциональная модель процесса управления проектом на стадии старта проекта представлена на рисунке 5.

Рисунок 5. Функциональная модель проекта, закрытие проекта

2.4 Обмен данных между системами

2.4.1 Общие сведения

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

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

2.4.2 Синхронизация информационных систем

Первый способ обмена данными - синхронизация с помощью шины данных (ESB - enterprise service bus). Шина данных - это система, которая получает информацию из мастер-системы, преобразует ее в нужную форму и отправляет ее во все системы, в которых также используется эта информация. Синхронизация является приоритетным методом обмена данных, так как при изменении на стороне мастер-системы не появляется необходимости вносить изменения во все смежные системы, достаточно доработать механизм передачи данных шиной и процесс преобразования данных. Обмен информации между шиной данных и смежными системами происходит с помощью файлов формата XSD. Такой формат позволяет передавать сущности, содержащие реквизиты определенного типа данных и осуществлять проверку соответствия данных заданному типу. Проверка корректности отправляемых данных осуществляется на всех этапах: отправка из мастер-системы, прием шиной данных, отправка из шины данных, прием системой-приемником. Частая проверка позволяет минимизировать риск повреждения файла в процессе передачи данных по каналам связи.

Синхронизация происходит в несколько этапов. Схема работы шины данных представлена на рисунке 6:

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

2. Формирование очереди в мастер-системе. После изменения данных мастер-системе обновленные данные записываются в XSD-файл, происходит проверка корректности файла. Затем файл помещается в очередь для отправки в шину данных.

3. Загрузка данных в шину. Согласно расписанию, мастер-система загружает XSD-файлы в шину данных.

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

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

6. Запрос данных у шины. В соответствии с расписанием, система-приемник запрашивает шину о наличии файлов для синхронизации в очереди по конкретной системе.

7. Отправка данных в систему-приемник. В случае, если в очереди имеются данные для синхронизации, шина отправляет все файлы в систему-приемник.

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

инструментальный информационный управление проект



Рисунок 6. Синхронизация нескольких систем между собой

2.4.3 Интеграция информационных систем

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

1. Запуск вызываемой системы. Пользователь работает в системе-источнике и запускает процесс, который требует подключения смежной системы. Система-источник напрямую передает информацию вызываемой системе с помощью XSD-файла, открывается форма вызываемой системы в соответствии с потребностями пользователя.

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

3. Завершение работы в вызываемой системе. После того, как пользователь совершил необходимые действия, он возвращается в систему-источник и продолжает свою работу. При этом вызываемая система возвращает системе-источнику результат обработки данных в формате XSD.

Рисунок 7. Интеграция одной системы в другую



Глава 3. Предлагаемые изменения в подходе к управлению проектами

3.1 Анализ текущего процесса

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

· Финансовые риски. Наиболее серьезный риск, связанный с проектной деятельностью заключается в выполнении нерентабельного проекта. Для его минимизации перед началом проекта привлекается экономист (система К2, функция «Согласование договора», рисунок 3), которой должен вынести экспертную оценку по показателям доходности проекта. Также происходит просчет плановых расчетов с клиентом (система Финансовый калькулятор, функция «Заполнение плановых данных договора», рисунок 3), что позволяет сравнивать реальные показатели, полученные в ходе проекта, с ожидаемыми (система Targit BI, функция «План-факт анализ, рисунок 4).

· Юридические риски. Перед заключением договора юрист компании выверяет текст договора (система К2, функция «Согласование договора», рисунок 3), чтобы тот полностью соответствовал законодательству и не вовлекал компанию в потенциально невыгодные сделки.

· Риски, связанные с контрагентами. Компания стремится к тому, чтобы работать с прозрачными и стабильными фирмами, гарантируя стабильные выплаты по выполненным работам и бесперебойные поставки оборудования. Для этого ответственное лицо компании выверяет данные по контрагентам и блокирует работу с потенциально рисковыми фирмами (система К2, функция «Согласование контрагента», рисунок 3).

· Риски, связанные с проектными работами. Отслеживание степени выполнения работ и сравнение ее с календарными планами (система Targit BI, функция «План-факт анализ», рисунок 4) позволяет менеджеру эффективно реагировать на отклонения в работе и минимизировать возможные риски.

· Риски, связанные с оппортунизмом. Компания предоставляет возможность менеджерам полностью контролировать загрузку проектной команды и выявлять случаи, когда тот или иной сотрудник начинает работать неэффективно, затрачивая большое количество рабочего времени на незначительные задачи (система CA Clarity, функция «План-факт анализ», рисунок 4). Также ход работ контролирует директор департамента (Система управления контрольными точками, функция «Утверждение контрольных точек», рисунок 4) и может вмешаться в проект для повышения его стабильности, если ситуация того требует.

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

Функциональная модель процесса управления проектами наглядно показывает тот факт, что в компании есть большое число различных систем. В первой главе данной работы были выделены четыре ключевые области, которые должны поддерживаться с помощью программного обеспечения. ЗАО «КРОК инкорпорейтед» имеет по крайней мере одну информационную систему, которая отвечает за поддержку функций, на каждую из областей, то есть всесторонне подходит к решению вопроса автоматизации процесса управления проектами. Такой вывод можно сделать, сопоставив четырем областям используемое программное обеспечение:

· Базовая поддержка управления проектами:

o Финансовый калькулятор

o 1С ERP

o Targit BI

· Управление знаниями:

o Microsoft CRM

o Jive

o OpenText Documentum D2

· Управление процессом:

o CA Clarity

o К2

o Система управления контрольными точками

· Поддержка общения и совместной работы:

o Atlassian Jira

Несмотря на то, что ЗАО «КРОК инкорпорейтед» тщательно подходит к работе с рисками, наличие большого числа разнообразных систем может быть не очень удобно для пользователей, так как они должны уметь ориентироваться во множестве различных интерфейсов и быстро находить нужный им блок в каждой из программ.

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

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

· низкая оперативность обновления, затрудняющие применение современных методов и технологий интеллектуальной обработки и анализа данных, а значит принятие управленческих решений;

· многократное дублирование данных;

· многообразие технологий хранения данных, существенно повышающее существующий уровень информационного обмена;

· низкий уровень масштабируемости из-за необходимости закупки новых серверов, которым необходимо обеспечить надежную сохранность данных и защиту от внешних угроз;

· сложность информационно-аналитической обработки информации, если необходимые данные находятся в разных системах;

· отсутствие единых форматов и технологий обработки информации, единых хранилищ данных;

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

3.2 Описание изменений для внедрения

3.2.1 Предлагаемые изменения

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

Таблица 1

Информационные системы хранилища и их данные

Информационная система	Таблицы, загружаемые в хранилище	Таблицы хранилища для использования
Microsoft CRM	· Контрагент	· Контрагент · Договор · Плановые данные проекта
CA Clarity	· Активность · Календарный план работ · Сотрудник · Трудозатраты	· Активность · Календарные планы проекта · Сотрудник · Трудозатраты
К2	· Статус согласования контрагента · Статус согласования активности · Статус согласования договора	· Контрагент · Активность · Договор · Сотрудник
Финансовый калькулятор (ФК)	· Плановые данные проекта	· Плановые данные проекта
1С ERP	· Договор · Склад · Номенклатура · Печатная форма · Транзакция · Тип транзакции · Валюта	· Договор · Склад · Номенклатура · Календарные планы проекта · Статус согласования контрагента · Статус согласования активности · Статус согласования договора · Транзакция · Тип транзакции · Валюта
Targit BI	-	· Контрагент · Активность · Договор · Склад · Номенклатура · Сотрудник · Плановые данные проекта · Транзакция · Тип транзакции · Валюта · Трудозатраты
OpenText Documentum D2	· Печатная форма	· Печатная форма
Atlassian Jira	· Трудозатраты	· Сотрудник · Трудозатраты

Для каждой информационной системы разрабатывается адаптер, позволяющий отправлять и получать нужные данные из хранилища в специализированном виде - контейнерах. Количество адаптеров соответствует количеству подключаемых систем. Каждый адаптер порождает контейнеры различных типов в соответствии с передаваемыми данными. Схема связи хранилища данных с информационными системами и банками данных представлена на рисунке 8.

Рисунок 8. Связь хранилища данных с информационными системами и банками данных

Рисунок 9. Укрупненная схема хранилища данных

Организация таблиц внутри хранилища построена по схеме снежинки, то есть таблицы измерений связаны с другими таблицами кроме таблицы фактов. Таблица фактов собирает информацию о финансовых потоках компании и трудозатратах на проведение каждой транзакции. Укрупненная схема хранилища представлена на рисунке 9.

Описания основных таблиц хранилища:

· Контрагент - содержит в себе данные по юридическим лицам, с которыми работает компания ЗАО «КРОК инкорпорейтед»;

· Активность - содержит в себе информацию о проектах компании;

· Календарный план работ - содержит в себе информацию о планах выполнения проектных работ;

· Сотрудник - содержит в себе данные по сотрудникам компании ЗАО «КРОК инкорпорейтед»;

· Трудозатраты - содержит в себе данные о затраченном рабочем времени сотрудников на определенные задачи;

· Статус согласования контрагента - содержит в себе информацию о процессе согласования контрагентов ответственными лицами компании;

· Статус согласования активности - содержит в себе информацию о процессе согласования активностей ответственными лицами компании;

· Статус согласования договора - содержит в себе информацию о процессе согласования договоров ответственными лицами компании;

· Плановые данные проектов - содержит в себе данные по плановой выручке проектов;

· Договор - содержит в себе записи о заключенных договорах компании ЗАО «КРОК инкорпорейтед» с поставщиками, клиентами и перевозчиками;

· Склад - содержит в себе информацию о складах для хранения товарных остатков компании;

· Номенклатура - содержит в себе данные о продаваемых товарах и работах компании;

· Печатная форма - содержит в себе информацию по файлам отсканированных документов с контрагентами;

· Транзакция - содержит в себе данные о проведении компанией ЗАО «КРОК инкорпорейтед» сделки по купле-продаже;

· Тип транзакции - содержит в себе информацию, была произведена покупка или продажа;

· Валюта - содержит в себе информацию о валютах, с которыми работает компания.

Создание единого хранилища данных имеет ряд преимуществ перед существующей архитектурой:

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

· обеспечение всех систем актуальными, полными, непротиворечивыми и достоверными данными единовременно;

· экономия места для хранения информации из-за отсутствия избыточности данных;

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

· сокращение сотрудников поддержки систем за счет вывода из использования шины данных и переноса функций ее поддержки на центральную систему технической поддержки;

· появления возможности внедрения технологии интеллектуального анализа «больших данных».

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

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

3.2.2 План внедрения изменений

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

1. Собрать информацию о хранимых сущностях в каждой из систем в инфраструктуре компании, их реквизитах, типах и пр.;

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

3. Разработать хранилище по составленным функциональным дизайнам разработки;

4. Протестировать корректность работы хранилища и обмен данными между разными системами на тестовых стендах;

5. Доработать хранилище по выявленным проблемам и провести отладку инфраструктуры

6. Провести внедрение и отследить корректность работы на рабочих стендах.

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

Подробные работы с указанием длительности, ресурсов и затрат приведены в таблице 2.

Таблица 2

План внедрения хранилища

Название задачи	Длите-льность	Название ресурсов	Трудо-затраты	Общие затраты
Анализ и составление ФДР	5 д		224 ч	168,000.00 ?
Анализ CRM	5 д	Ведущий консультант	40 ч	30,000.00 ?
Анализ Clarity	3 д	Ведущий консультант	24 ч	18,000.00 ?
Анализ К2	3 д	Ведущий консультант	24 ч	18,000.00 ?
Анализ ФК	3 д	Ведущий консультант	24 ч	18,000.00 ?
Анализ ERP	5 д	Ведущий консультант	40 ч	30,000.00 ?
Анализ BI	5 д	Ведущий консультант	40 ч	30,000.00 ?
Анализ D2	2 д	Ведущий консультант	16 ч	12,000.00 ?
Анализ Jira	2 д	Ведущий консультант	16 ч	12,000.00 ?
Разработка	15 д	Ведущий разработчик, Разработчик [500%]	720 ч	270,000.00 ?
Тестирование	4 д		256 ч	76,800.00 ?
Тестирование CRM	4 д	Тестировщик	32 ч	9,600.00 ?
Тестирование Clarity	4 д	Тестировщик	32 ч	9,600.00 ?
Тестирование К2	4 д	Тестировщик	32 ч	9,600.00 ?
Тестирование ФК	4 д	Тестировщик	32 ч	9,600.00 ?
Тестирование ERP	4 д	Тестировщик	32 ч	9,600.00 ?
Тестирование BI	4 д	Тестировщик	32 ч	9,600.00 ?
Тестирование D2	4 д	Тестировщик	32 ч	9,600.00 ?
Тестирование Jira	4 д	Тестировщик	32 ч	9,600.00 ?
Доработка и отладка	5 д		560 ч	186,000.00 ?
Доработка	5 д	Ведущий разработчик, Разработчик [500%]	240 ч	90,000.00 ?
Тестирование CRM	5 д	Тестировщик	40 ч	12,000.00 ?
Тестирование Clarity	5 д	Тестировщик	40 ч	12,000.00 ?
Тестирование К2	5 д	Тестировщик	40 ч	12,000.00 ?
Тестирование ФК	5 д	Тестировщик	40 ч	12,000.00 ?
Тестирование ERP	5 д	Тестировщик	40 ч	12,000.00 ?
Тестирование BI	5 д	Тестировщик	40 ч	12,000.00 ?
Тестирование D2	5 д	Тестировщик	40 ч	12,000.00 ?
Тестирование Jira	5 д	Тестировщик	40 ч	12,000.00 ?
Внедрение	1 д	Ведущий консультант	8 ч	6,000.00 ?

Таким образом предполагается, что внедрение произойдет за 30 рабочих дней (~1.5 календарных месяца), бюджет составит 706 800 рублей. Для внедрения необходимо выделить 8 ведущих консультантов (по одному от каждой системы, которая будет участвовать в обмене данными), 6 разработчиков, один из которых будет ведущим, и 8 тестировщиков (по одному от каждой системы).

3.3 Ожидаемый экономический эффект

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

1. Поддержка информационных систем компании

На данный момент существует команда консультантов, которая ответственна за поддержку шины данных. С внедрением единого хранилища данных компания сможет отказаться от такой поддержки из-за ненадобности самой системы. С другой стороны, должна существовать поддержка хранилища данных, так как оно становится одной из наиболее важных частей инфраструктуры, отказ работы которого может стать критичным для работы компании в целом. Эти функции можно передать от консультантов к инженерам центральной службы технической поддержки (ЦСТП), так как ошибки со стороны систем будут исправлять консультанты поддержки самой системы, а исправление ошибок в хранилище потребует знания технической составляющей. Состав текущей команды поддержки шины данных приведен в таблице 3. Состав предполагаемой поддержки хранилища данных приведен в таблице 4.

...