Разработка стратегического плана автоматизации компании

Мы пришли к выводу, что проще и выгоднее приобрести, готовый продукт. Изучив все варианты, мы выбрали систему Microsoft Windows Small Business Server 2003 R2 Standard.

Её основными преимуществами, являются:

• Содержит все базовые серверные продукты Microsoft (Windows Server 2003, Exchange Server 2003 и др.) без каких-либо ограничений по функционалу;

• Значительно дешевле, чем покупать продукты отдельно;

• Упрощённый процесс установки и выполнения базовых задач, таких как подключение к Интернету, заведение почтовых ящиков, сбора статистики и др.

Ограничения системы:

• Работает только с небольшими сетями (до 75 компьютеров)

• Объединение сетей разных организаций не поддерживается

• Работа терминального сервера приложений возможна только на дополнительной операционной системе

• Продукт должен быть установлен на один сервер

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

Для приобретения и установки системы мы обратимся в фирму - партнер компании Microsoft, IMANGO. Стоимость продукта 8 000 руб.

Помимо ОС необходимо приобрести программное обеспечение:

• MS Office 12000 (На всю сеть);

• Eset Software Антивирус NOD32 Standard newsale for 1 user [NOD32-STD-NS-1-1] 850 руб. , на один компьютер, итого 6800 руб.;

• 1С Бухгалтерия, базовая версия 3000 руб.;

• Opera browser: Homepage – условно бесплатный продукт;

• ISQ - условно бесплатный продукт;

• Skype - условно бесплатный продукт;

• WinRar – 850 руб.

Итого по программному обеспечению 30650 руб.

3. Базы данных:

Необходимо создать 2 базы данных:

1. База данных психологических инструментов.

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

2. База данных клиентов.

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

• Имя

• Фамилию

• Отчество

• Дату рождения

• Фамилию психологов, работавших с ним

• Результаты тестирований, тренингов ит.д.

• Краткая характеристика психолога

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

3. Сайт:

Предполагается создание Web – сайта, МУ «Гармонии». На нем будет расположена вся необходимая информация о психологическом центре, в том числе последние новости, а т.ж. представлены варианты online – тестов и тренингов. Сайт будет включать в себя форум, где потенциальные и действительные клиенты смогут задать все интересующие их вопросы и обсудить работу МУ «Гармонии». Важным достоинством этого информационного ресурса станет возможность online – консультаций. Человек сможет не выходя из собственного дома, получить квалифицированную помощь психолога.

4. Персонал:

Для эффективного функционирования МУ «Гармония», в условиях современной экономики, и полноценного использования внедряемого комплекса ИС и ИТ, необходимо провести реструктуризацию персонала организации. Во-первых, необходимо расширить и специализировать психологический персонал. В связи с этим, было принято решение, отправить на курсы  повышения квалификации работающих в МУ «Гармония» психологов (в результате требуется получить специалистов в подростковой и взрослой психологии), а так же нанять еще 3 специалистов, в области детской психологии, работы с организациями и психолога широкого профиля, с последующим его обучением для online – консультаций. Для обслуживания локальной сети, обучения и последующего консультирования  её пользователей, а так же другой помощи в работе с ИС и ИТ, необходимо нанять Специалиста в области ИТ, на должность системного администратора. В связи с расширением деятельности организации, ростом её персонала, усложняется документооборот, поэтому необходимо принять на постоянной основе бухгалтера. В результате организационная структура МУ «Гармония» изменится и примет вид, изображенный на рисунке 3.

 

Рисунок 3 Организационная структура МУ «Гармония», после реализации СПИС

 

 

 

 

 

 

Управление рисками

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

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

1. Риски для проекта, которые влияют на график работ или ресурсы, необходимые для выполнения проекта.
2. Риски для разрабатываемого продукта, влияющие на качество или производительность разрабатываемого программного продукта.
3. Бизнес-риски, относящиеся к организации-разработчику или поставщикам.  
   

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

Риск	Типы Риска	Описание риска
Текучесть разработчиков	Риск для проекта	Опытные разработчики покидают проект до его завершения
Изменение в управлении организацией	Риск для проекта	Организация меняет свои приоритеты в управлении проектом
Неготовность аппаратных средств	Риск для проекта	Аппаратные средства, которые необходимы для проекта, не поступили вовремя или не готовы к эксплуатации
Изменение требований	Риск для проекта и для разрабатываемого продукта	Появление большого количества непредвиденных изменений в требованиях, предъявляемых к разрабатываемому ПО
Задержка в разработке спецификации	Риск для проекта и для разрабатываемого продукта	Спецификации основных интерфейсов подсистем не поступили к разработчикам в соответствии с графиком работ
Недооценка размера разрабатываемой системы	Риск для проекта и для разрабатываемого продукта	Размер системы значительно превысил первоначальную оценку
Недостаточная эффективность CASE-средств	Риск для разрабатываемого продукта	CASE-средства, предназначенные для  поддержки проекта, оказались менее  эффективными, чем ожидалось
Изменения в технологии разработки ПО	Бизнес-риск	Основные технологии построения программной системы заменяются новыми
Появление конкурирующего программного продукта	Бизнес-риск	На рынке программных продуктов до окончания проекта появилась конкурирующая программная система

 

 

Схема процесса управления рисками показана на рис. 6. Этот процесс состоит из четырех стадий. 

1. Определение рисков. Определяются возможные риски для проекта, для разрабатываемого продукта и бизнес-риски.
2. Анализ рисков. Оценивается вероятность и последовательность появления рисковых ситуаций.
3. Планирование рисков. Планируются мероприятия по предотвращению рисков или минимизации их воздействия на проект.
4. Мониторинг рисков. Постоянное оценивание вероятностей рисков и выполнение мероприятий по смягчению последствий проявления рисковых ситуаций.  
   

 

Рис.6 Процесс управления рисками

Определение рисков

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

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

1. Технологические риски. Проистекают из программных и аппаратных технологий, на основе которых разрабатывается система.
2. Риски, связанные с персоналом. Связаны с членами команды разработчиков.
3. Организационные риски. Проистекают из организационного окружения, в котором выполняется проект.
4. Инструментальные риски. Связаны с используемыми CASE-средствами и другими средствами поддержки процесса создания ПО.
5. Риски, связанные с системными требованиями. Проявляются при изменении требований, предъявляемых к разрабатываемой системе.
6. Риски оценивания. Связаны с оцениванием характеристик программной системы и ресурсов, необходимых для реализации проекта. 
   

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

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

 

 

 

Анализ рисков

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

1. Вероятность риска считается очень низкой, если она имеет значение менее 10%; низкой, если ее значение от 10 до 25 %; средней при значениях от 25 до 50%; высокой, если значение колеблется от 50 до 75%; очень высокой при значениях более 75%.
2. Возможный ущерб от рисковых ситуаций можно подразделить на катастрофический, серьезный, терпимый и незначительный.

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

Таблица 6 - Список рисков после проведения их анализа

Риск	Вероятность	Степень ущерба
Финансовые затруднения в организации привели к уменьшению бюджета проекта	Низкая	Катастрофическая
Невозможно подобрать работников с требующимся профессиональным уровнем	Высокая	Катастрофическая
Ведущий разработчик заболел в самое критическое время	Средняя	Серьезная
Программные компоненты, используемые повторно, имеют дефекты, ограничивающие их функциональные возможности	Средняя	Серьезная
Изменения требований приводят к значительным повторным работам по проектированию системы	Средняя	Серьезная
В организации, выполняющей разработку ПО, произошла реорганизация, в результате чего изменились приоритеты в управлении проектом	Средняя	Серьезная
База данных, которая используется в программной системе, не обеспечивает обработку ожидаемого объема транзакций	Средняя	Серьезная
Недооценки времени выполнения проекта	Высокая	Серьезная
CASE-средства невозможно интегрировать  с другими средствами поддержки  проекта	Высокая	Терпимая
Первоначальная нечеткая формулировка пользовательских требований привела к значительным изменениям системных требований, проявившихся на поздних стадиях разработки проекта	Средняя	Терпимая
Невозможно организовать необходимое обучение персонала	Средняя	Терпимая
Скорость выявления дефектов в системе ниже ранее спланированной	Средняя	Терпимая
Размер системы значительно превышает первоначально рассчитанный	Высокая	Терпимая
Программный код, генерируемый CASE-средствами, неэффективен	Средняя	Незначительная