Системы управления ресурсами предприятия

По данным самой компании, 57% доходов получено от оказания услуг, 43% – от поставки лицензий. Наибольшая концентрация заказов в нефтегазовом комплексе (18,3%), машиностроении (18%) и связи (12,7%); значительные доли имеют также химическая промышленность, транспорт, лесопереработка, торговля, горнодобывающая промышленность и электроэнергетика.

Epicor Scala

Система Scala впервые была представлена на рынке СНГ в 1991 г. Scala СНГ стала первой среди компаний, предлагающих программные средства и услуги по управлению бизнесом, финансами и производством на территории СНГ и Восточной Европы. C 2004 г. компания стала частью корпорации Epicor, которая уже более 20 лет остается лидером в области интегрированных систем планирования корпоративных ресурсов (ERP), управления взаимоотношениями с заказчиками (CRM) и управления цепочками поставок (SCM) для среднего бизнеса во всем мире.

Абсолютные финансовые показатели работы в странах СНГ руководством Epicor-Scala не раскрываются; структура доходов в этом регионе следующая: 47% – поддержка старых клиентов, 28% – консалтинг и 25% – продажа лицензий. За 12 лет общее число заказчиков, использующих продукты Epicor и Scala, достигло 600, причем 70% из них эксплуатируют системы Scala.

1С

ЗАО "1С" было основано в 1991 г. Широкое распространение продуктов 1С во многом обусловлено тем, что "1С" работает с пользователями через самую разветвленную на компьютерном рынке СНГ партнерскую сеть.

"1С" не ограничивается продажей собственных разработок. Фирма – официальный дистрибьютор программного обеспечения Miсrosoft, Novell, Symantec, Intel и других зарубежных фирм.

20

Продажи программного обеспечения на внутреннем рынке увеличились на 60%, мультимедиа – на 30%, а объем дистрибуции ПО западных вендоров вырос на 29%.

BAAN Eurasia

Компания Baan официально вышла на российский рынок в 1997 г. через компанию "БААН-Евразия".

Стоимость поставки и внедрения системы Baan для среднего предприятия (работа в системе 100-150 человек) оценивается в $600-800 тыс. По другой информации стоимость поставки лицензии Baan на 1 пользователя составляет $3000, а стоимость конкурентной лицензии (с ограничениями по одновременному подключению к базе данных) – $6000. При этом стоимость внедрения Baan обычно больше стоимости поставки в несколько раз.

Контрольные вопросы.

1.Группы, от которых зависит принятие решений в сфере ИТ.

2.Основные аспекты развития предприятий и внешней среды и их влияние на роль ИТ в управлении предприятием.

3.Классификация управленческой деятельности.

4.Задачи корпоративных информационных систем управления предприятием

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

6.Ведущие производители систем АУД.

21

1.2. Планирование проекта

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

−изделие неосязаемо. Нельзя утверждать, что мост на 90 % построен, если нет 90 % моста в наличии. Можно сказать, что программный проект на 90 % реализован, даже если нет видимых результатов;

−отсутствие достаточного опыта в данной области. Разработка программного обеспечения новая дисциплина, и поэтому мы просто не имеем представления о том, как разрабатывать крупномасштабные проекты программного обеспечения;

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

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

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

•Самая большая основная проблема, которая препятствует развитию программного обеспечения – это недооценка ресурсов, необходимых для проекта.

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

•Типы плана:

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

22

−план проверки качества определяет процедуры для определения качества и стандарты, которые будут использоваться;

−план ратификации определяет приемку программного продукта заказчиком;

−план управления конфигурацией определяет, как система будет сконфигурирована и установлена;

−план обслуживания определяет, как система будет

сопровождаться;

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

Мы сосредоточимся на плане разработки программного обеспечения и плане проверки качества.

1.2.1.План разработки программного обеспечения

•это то, что называется планом проекта, и определяет порядок работ, которые необходимо выполнить, ресурсы, обязанности, и так далее.

•может быть, как маленьким и относительно неформальным, так и большим, и полностью официальным.

•создание плана проекта столь же важно, как и само проектирование кода:

на основе плана проекта, подписываются контракты и достигается или не достигается успех...

•Важно не:

–переоценить способности вашей команды;

–говорить клиентам просто то, что они хотят услышать;

–оказываться под давлением разработчиков («мы можем сделать это днем!»)

23

1.2.2.Структура плана разработки

а) краткое введение к проекту – ссылки на основные требования; б) организация проекта. Введение к организации проекта, сотрудники, и их роли;

в) анализ рисков – какие риски являются ключевыми в данном проекте?

г) какие аппаратные средства ЭВМ и программные ресурсы потребуются для проекта и когда?

д) классификация действий по реализации проекта – проект делится на действия, вехи, внедрения; зависимости между задачами и т. д.; е) график выполнения работ по проекту. Фактически необходимое время – распределение по датам;

ж) контроль за ходом выполнения работ и отчет о нем; механизмы контроля хода выполнения работ.

1.2.3.Классификация действий по реализации проекта

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

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

Задача – обычно значительно меньшая по объему работа. Это часть рабочего пакета, обычно 3–6 человек/месяцев; может зависеть от другого параллельного действия; обычно выполняется одним человеком.

Внедрения – выход проекта, который может быть реально оценен.

24

Примеры: отчет (например, список требований к системе); программа (например, альфа версия изделия).

Внедрения – индикаторы хода выполнения работы.

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

Примеры: составление списка требований к системе; внедрение альфы версии программы.

Рабочие пакеты обозначаются WP1, WP2...; задачи обозначаются T1.1, T1.2, и т. д.; первое число – номер рабочего пакета; второе – порядковый номер.

Внедрения обозначаются D1.1, D1.2, и т. д.; вехи обозначаются M1, M2 и т. д.

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

1.2.4.Критические пути

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

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

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

25

Графическими средствами планирования могут быть диаграммы Ганта и сетевые графики (см. Словарь определений).

Контрольные вопросы.

1.Свойства проектов программного обеспечения

2.Управление проектом программного обеспечения: действия, проблемы, типы планов

3.План разработки программного обеспечения: структура, используемые понятия и графические представления

1.3.Классические схемы разработки корпоративных систем

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

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

26

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

27

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

Схема такой организации приведена на рис. 4.

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

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

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

29