Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

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

Курсовая работа

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

стратегический цель совершенствование компания

Введение

1 .Стратегический анализ деятельности компании

1 .1 Обоснование выбора организации

1 .2 Организационно-штатная структура

1 .3 Основные проблемы управления

1 .4 Постановка стратегических целей

1 .5 Анализ и выбор стратегии

2 .анализ и оптимизация бизнес-процессов

2 .1 Описание бизнес-процессов «как есть»

2.2 Проблемы и задачи

2 .3 Анализ типовых вариантов процессов разработки

2 .4 Оптимизация процессов разработки и сопровождения

3 .1 Описание бизнес-процессов «как должно быть»

3.2 Изменения в организационно-штатной структуре

3 .3 Регламентирование деятельности

3 .4 Перспективные направления автоматизации

Заключение

Список использованной литературы

Приложение

Образцы внутренних документов

Приложение

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

Приложение

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

Приложение

Регламент исполнения заявок на обслуживание и сопровождение

Приложение

Типовая должностная инструкция специалиста-стажера Управления разработки прикладных систем

Приложение

Типовые квалификационные требования к сотрудникам Управления разработки прикладных систем

Введение

Данная аттестационная работа направлена на описание и оптимизацию бизнес-процессов компании-разработчика программного обеспечения (далее - ПО).

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

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

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

Стратегический анализ деятельности компании;

Описание текущего положения и штатной структуры компании;

Описание существующих бизнес-процессов;

Анализ и оптимизация бизнес-процессов, выработка рекомендаций по их изменению, регламентирование деятельности;

Оптимизация штатной структуры компании;

Анализ проблем и выработка решений по управленческим и кадровым проблемам компании;

Создание образцов типовых документов;

Определение перспективных направлений автоматизации деятельности.

1.Стратегический анализ деятельности компании

1.1 Обоснование выбора организации

В качестве исследуемой организации выбрана ООО «Кварта».

Основными направлениями деятельности компании являются:

Разработка программного обеспечения (ПО);

Внедрение и сопровождение программного обеспечения;

Поставка аппаратного обеспечения;

Техническая поддержка.

При этом разработка ПО ведется в двух направлениях - ПО сферы бухгалтерского учета разрабатывается на одной платформе, а ПО остальных направлений - на другой (т.н. ИИС).

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

Организационно-штатная структура компании еще больше усугубляет вышеуказанные проблемы.

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

Описание организации приведено в Таблице 1.

Таблица 1.Описание организации как объекта управления

Параметр описания	Характеристика
Название, местонахождение	ООО «Кварта», г. Москва
Назначение	Оказание услуг автоматизации для федеральных и территориальных органов государственной власти, бюджетных учреждений, а также для малых и средних предприятий (разработчик и поставщик услуг по внедрению и сопровождению автоматизированных информационных систем (АИС), системная интеграция)
Отраслевая принадлежность	Отрасли третичного цикла Частная фирма Информационные технологии
Правовая форма и вид собственности	Коммерческое предприятие, общество с ограниченной ответственностью, частное
Историческая справка	Образовалась в 1993 году. Первый заказчик Управление делами Президента РФ Начало создания финансово-бухгалтерской системы, организация ЛВС. Постепенно в компании образовался ряд направлений деятельности, которые впоследствии переросли в отдельные компании («Кварта-технологии», «Кварта-сети», «Кварта-консалтинг», Кадровое агентство «Кварта», «Сенсорные системы» и др.). Непосредственно сама компания занялась разработкой интегрированных информационных систем управления предприятием (ИИС), а также комплексной автоматизацией организаций и предприятий. Основным направлением деятельности были выбраны федеральные органы законодательной и исполнительной власти РФ. На данный момент заказчиками услуг компании являются Аппарат Правительства, Государственная Дума, Совет Федерации, Счётная палата, УД Президента РФ и большая часть Министерств, федеральных служб и агентств, включая подведомственные организации и загранучреждения, а также коммерческие организации различных форм собственности. Список предоставляемых услуг постоянно растёт, появляются новые продукты. В планах компании расширить влияние в секторе муниципальных образований и продвижение в регионы. Также компания постепенно расширяет деятельность в секторе коммерческих предприятий.
Организационная структура	См. ниже (Модель «Цепочки ценностей»)
Структура управления	В данный момент компания использует вертикальную систему управления от генерального директора к руководителям структурных подразделений (департаментов), часть из которых выполняет функции заместителей, далее к начальникам отделов и групп. Подразделения поделены по функциональному признаку. В последнее время в связи с большим количеством разнородных проектов, требующих специалистов разных направлений, постепенно вводится практика назначения руководителей проектов (как правило руководители отделов) и планируется серьёзная структурная реорганизация.
Параметр описания	Характеристика
	Основной ресурс - сотрудники. Поощрение инициативных сотрудников, дружеская атмосфера в коллективе. Большое внимание уделяется обучению. Репутация в секторе разработки ПО для федеральных органов, рекомендации клиентов. Накопленный опыт, знание до тонкостей специфики работы в данном секторе. Многолетний опыт работы и большое количество завершенных проектов, что позволяет участвовать и выигрывать конкурсы. Технические ресурсы: помещения, коммуникации (телефония, широкополосный доступ в Интернет), вычислительная техника, транспорт.
Культура	Высокая мотивация сотрудников, преданность фирме, устоявшийся коллектив, дружественные отношения в коллективе, знание целей и перспектив.
Ключевые факторы внешней среды	Законодательство: Изменчивое законодательство, постоянные нововведения, часто не подкреплённые методическими рекомендациями, ограниченное время на реализацию изменений. Заказчики: Специфика данного рынка (федеральные органы власти) в том, что на процесс разработки / внедрения дается очень мало времени. Часто через несколько дней после подписания контракта система должна полностью функционировать и быть наполненной информацией. Многое делается по принципу «надо вчера». Как правило, отсутствие единых стандартов, руководство заказчиков часто дает противоречивые указания, диктует собственные условия, часто расходящиеся с реальностью. Ограниченное, часто запаздывающее финансирование. Как правило, платформы для приложений определены заранее, поэтому необходим большой арсенал версий под разные платформы. Конкуренция: Конкуренция высокая, как правило, выигрывает не лучший продукт или предложение, а лучшая протекция со стороны заказчика. Каждый руководитель имеет свои устоявшиеся связи и поставщиков, поэтому часто борьба идет не за конкурентные преимущества, а за протекцию. Новые игроки как правило отсутствуют, конкурируют как правило компании с устоявшейся клиентской базой, по причине того, что в данном сегменте требуется большой опыт и специфическое отношение к заказчикам. Технологии: сильная зависимость от тенденций развития технологий, необходимость следовать за тенденциями рынка, плюс необходимость поддержки большинства актуальных технологий.
Руководство	Генеральный директор, он же собственник: оперативное управление деятельностью компании, консолидированная стратегия, участие в переговорах с ключевыми заказчиками. Также в данный момент есть 3 заместителя, они же являются руководителями основных департаментов компании. Каждый ведет свой круг вопросов в рамках департамента, выработку стратегии своего направления, переговоры и пр. и осуществляет координацию с другими подразделениями.
Параметр описания	Характеристика
Модель «Цепочки ценностей»	Процессы основной деятельности: Разработка: выпуск качественных и функциональных продуктов с максимальным функционалом, необходимым заказчику. Следование новым технологиям и поддержка большого количества платформ. Интеграция: полный комплекс услуг, начиная с этапа сбора информации и проектирования, до сдачи в эксплуатации функционирующих в соответствии с требованиями заказчика программно-аппаратных комплексов Сопровождение: ключевой особенностью является постоянная поддержка систем у заказчика. Компания никогда не оставляет заказчиков один на один с информационной системой. Как правило при необходимости у заказчика присутствуют сотрудники компании, часто выделяются постоянные представители. Это позволяет существенно улучшить быстроту и качество обслуживания. Поставки: поставка любых аппаратно-программных продуктов различных производителей, настройка, адаптация, ввод в эксплуатацию. Широкие партнёрские отношения с производителями. Предоставление услуг: также компания специализируется на предоставлении услуг по обслуживанию компаний, с уже работающей аппаратно-программной инфраструктурой, осуществляет, разрабатывает заказные продукты. Поиск заказчиков: мониторинг проводимых конкурсов, выбор оптимальных предложений, подготовка конкурсной документации, участие в конкурсах, итоговая документация Процессы вспомогательной деятельности: Разработка систем для внутреннего пользования Поддержка программно-аппаратной части компании Управление персоналом (мотивация, обучение и пр.) Снабжение Внутренний финансово-бухгалтерский учёт Технологические исследования Делопроизводство

1.2 Организационно-штатная структура

Существующая штатная структура организации приведена на Рисунке 1.

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

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

Кадровая служба не существует в виде отдельного подразделения.

Рисунок 1. Существующая штатная структура.

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

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

1.3 Основные проблемы управления

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

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

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

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

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

Отсутствие планирования. Часто приводит к авральному выполнению проектов и нехватке сотрудников.

Слаборазвитая система отчётов и документирования проектов. Это влечёт за собой недостаточную информированность, а иногда даже частичную незаменимость сотрудника, участвовавшего в конкретном проекте

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

1.4 Постановка стратегических целей

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

Миссия

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

Стратегический профиль

Текущую стратегию я бы сформулировал следующим образом:

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

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

Видение (стратегическое намерение)

1. Какой мы хотим видеть свою организацию в будущем?

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

2. Что из себя представляет наш бизнес сейчас и каким он будет в будущем?

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

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

3. Кто является потребителями нашей продукции (услуг) и на какую группу покупателей организация будет ориентироваться в будущем?

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

4. Какими способами мы собираемся увеличивать ценность нашей продукции для потребителей?

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

Стратегические цели

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

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

2. Генеральная цель.

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

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

Завершить реорганизацию структуры (создание новых структурных подразделений и распределение функций между ними)

Выделение в отдельную структуру аналитиков и проектировщиков.

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

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

Создать систему обучения вновь принятых сотрудников

Внедрить систему аттестации сотрудников

Организовать процесс повышения профессиональной подготовки кадров

Проведение тематических семинаров

Формализовать процессы.

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

Перейти к грамотной, качественной и формализованной постановке задач

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

Стандартизировать процессы планирования и отчётности

1.5 Анализ и выбор стратегии

Результаты SWOT-анализа приведены в таблице 2 и таблице 3.

Таблица 2.Анализ факторов, воздействующих на достижение стратегических целей

Сильные стороны организации
Слабые стороны организации
		Низкий уровень менеджмента организации, структура, не отвечающая текущим требованиям
Возможности окружающей среды
		Увеличение финансирования по программе «Электронная Россия», рост ИТ-рынка в целом
Угрозы окружающей среды

Таблица 3.Итоговая стратегическая матрица

	Сильные стороны организации	Слабые стороны организации
Возможности	S3-O2 Увеличение объемов поставок решений заказчикам S4-O3 Рост количества клиентов S1-O3 Расширение линейки продуктов S3-O1 Практически монополия по ряду поставляемых задач S2-O2 Возможность работы в кредит S4-O1 Возможность получения дополнительных разрешений S2-O1 Возможность выпускать продукты с соотв. с самыми современными технологиями	W1-O3 Использовать средства для модернизации линейки продуктов, вкладывать в новые технологии W3-O2 Возможность планирования работ заранее, оптимальное использование ресурсов W1-O1 Использование партнёрской поддержки для скорейшего освоения последних технологий W2-O3 Реорганизация системы управления, поиск профессиональных кадров
	S1-T1 Возможность текучки кадров. Повышать заинтересованность, постоянный мониторинг. S2-T1 Не терять финансовую независимость, что позволит существовать в кризисные моменты достаточно продолжительное время, предоставлять возможность работы в кредит S3-T3 Постоянно отслеживать изменение технологий, заниматься перспективными разработками. S2-T2 выпускать новый продукт раньше, чем конкуренты	W1-T3(Т1) Как можно скорее перейти на более совершенную платформу W3-T1(Т2) Отслеживать состояние рынка, тщательно планировать деятельность W2-T2 Привести структуру в соответствие с возникшей необходимостью, повышать квалификацию менеджеров

Граф типовых стратегий организации приведен на рисунке 2.

Выбор и обоснование стратегии

В таблице 4 приведен выбор и оценка факторов, задействованных в трёх базовых стратегиях.

Таблица 4.Выбор и оценка факторов, задействованных в трёх базовых стратегиях

		Реструктуризация (лидерство по издержкам)	Дифференциация	Комбинированная стратегия
		Удельный вес фактора		Удельный вес фактора	Средне-взвешенная оценка фактора	Удельный вес фактора	Средне-взвешенная оценка фактора

По сумме оценок:

По сумме оценок наилучшей стратегией является стратегия дифференциации.

По реальности задействованных факторов:

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

Выбранная стратегия

Возможные действия в рамках реализации стратегии:

Совершенствование и расширение линейки продуктов

Повышение профессионального уровня сотрудников

Повышение значимости планирования.

Агрессивная маркетинговая политика расширение партнёрских отношений.

Возможные последствия реализации выбранной стратегии

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

К недостаткам можно отнести следующее:

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

Надо очень серьёзно прорабатывать данные вопросы во избежание негативного влияния.

Реализация системы планов. Эффективность изменений

Определение необходимых изменений приводится в таблице 5.

Таблица 5.Определение необходимых изменений

	Наименование
	Сплоченный, высокопрофессиональный коллектив.			Держать уровень оплаты труда на рыночном уровне, предоставлять бонусы и гарантии. Разработать программы мотивации и повышения квалификации персонала, ввести аттестацию.
	Хорошая технологическая база, финансовая независимость			Технологическая база должна соответствовать современному уровню, обновлять при необходимости, использовать имеющиеся возможности для привлечения перспективных клиентов (кредит…)
	Актуальные инновационные разработки, учитывающие специфику рынка			Поддерживать высокое качество продуктов, уделять больше внимания заказчикам. Донести до потенциальных заказчиков преимущества (маркетинговая программа), всегда быть в курсе последних изменений, выводить на рынок продукты раньше конкурентов.
	Отличная репутация и долгов время пребывания на рынке
	Две линейки однородных продуктов, одна из которых использует устаревшую платформу			Отказаться от разработки двух линеек продуктов, перевести их на единую интегрированную платформу, сделать продукт современным и качественным. Постоянно проводить инновационные исследования и создать непрерывный цикл периодических обновлений.
	Низкий уровень менеджмента организации, структура не отвечающая текущим требований			Реорганизация структуры компании, формализация процессов, ввод в эксплуатацию внутренней информационной системы и рамках неё систем планирования, отчётности и пр. Обучение руководящего состава, привлечение новых кадров.
	Отсутствие маркетинговой политики и долгосрочного планирования			Разработка маркетинговой стратегии. Выработка стратегических планов и направлений развития компании на основе имеющихся знаний и возможностей.
	Наличие лицензий и разрешений соответствующих органов, партнёрство с поставщиками СУБД и системного ПО			Развивать партнёрские отношения с поставщиками. Лицензировать деятельность и обеспечивать наличие разрешений во всех требуемых направлениях.
	Наличие действующих контрактов, необходимых связей, владение необходимой информацией			Обеспечивать качественное выполнение контрактов с целью их продления, расширения услуг и повышения репутации. Расширять связи с целью своевременного получения информации.
	Увеличение финансирования по программе «Электронная Россия», рост ИТ рынка в целом			Развивать маркетинговую политику, активно участвовать в конкурсах, предлагать качественные, функциональные, опережающие конкурентов продукты
	Снижение финансирования госсектора, финансовые потрясения			Иметь резервные фонды и возможность предоставления услуг в кредит, широкий спектр продуктов и услуг. Поддерживать коллективный дух и корпоративные ценности.
	Риск активизации текущих игроков рынка			Вести активный мониторинг рынка. Владеть информацией. Иметь широкую продуктовую линейку с сильными конкурентными преимуществами.
	Зависимость от тенденций рынка в области платформ разработки			Активно сотрудничать с поставщиками, развивать партнёрские отношения. Повышать профессиональный уровень сотрудников, заниматься инновационными разработками.

Разработка мероприятий, программ и планов

Планирование

1. Создание плана реорганизации.

2. Планирование рабочего времени сотрудников.

3. Создание маркетингового плана

4. Создание плана обучения и переподготовки персонала

Организация

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

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

2. Разработка всех технических регламентов и формализация процессов.

3. Написание детальных должностных инструкций

4. Детальное распределение полномочий и распределение проектов. Назначение ответственного за результат.

Мотивация

В таблице 6 приводятся показатели качества трудовой жизни.

Таблица 6.Показатели качества трудовой жизни

Показатель	Положение в данный момент
Справедливая заработная плата
Рыночная оплата труда	Присутствует (но ближе к нижней планке). Есть институт премирования по итогам года и завешенных проектов, но носит субъективный характер.
Обоснованная дифференциация оплаты труда	В зависимости от должности
Индивидуальная ответственность за результаты общего труда	Присутствует, начиная со среднего уровня, но никоим образом не отражается в оплате труда
Доп. вознаграждение за длительный стаж работы в компании	Фактически отсутствует
Программа дополнительных выплат
Выплата работнику и его семье в случае болезни	да, по базовой ставке оплаты труда
Оплачиваемое время отпуска в связи с праздниками и отпусками	да, в соответствии с КЗОТ
Оплачиваемые отпуска для дополнительного образования	Оплачиваются в случае, если обучение происходит по направлению фирмы
Условия безопасности труда и охраны здоровья	на уровне «здравого смысла»: все используемое оборудование в работе соответствует международным стандартам безопасности, офисные площади планируются из рекомендованных санитарных норм.
Гарантия занятости
Обеспечение непрерывности трудового стажа	да, в соответствии с КЗОТ
Уверенность работников в своем будущем	Да, стабильная компания, 15 лет на рыке.
Развитие способностей работников	Обучение происходит стихийно или по необходимости.
Социальная интеграция
Социально-психологический микроклимат в организации	Нейтральный. Много как позитивных, так и негативных моментов. Присутствует некая обособленность структурных единиц.
Отношение руководства и подчиненных	Между руководителями подразделений и подчиненными- ближе к демократическому.
Участие работников в управлении производством и собственностью, поощрение инициатив и новых идей	1. Поощрение инициативности сотрудников и внедрение их идей зависит в большинстве случаев от руководителей структурных единиц и их видения ситуации. Т.е. в некоторых подразделениях это поощряется, в некоторых игнорируется и исключается. 2. Управление собственностью: скорее исключает участие сотрудников в качестве партнеров по бизнесу.

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

Контроль

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

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

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

Оценка эффективности предлагаемых изменений

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

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

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

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

2. А нализ и оптимизация бизнес-процессов

2.1 Описание бизнес-процессов «как есть»

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

Разработка

Процесс разработки новых прикладных систем, как правило, состоит из следующих видов деятельности (Рисунок 3):

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

Разработка;

Тестирование;

Документирование.

Рисунок 3. Виды деятельности при разработке новых систем и роли

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

Диаграмма деятельности для стадии постановки задачи приведена на Рисунке 4.

Рисунок 4. Диаграмма деятельности для стадии постановки задачи

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

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

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

Контроль над процессом является эпизодическим, осуществляется в основном уже непосредственно перед сдачей проекта. Официальная оценка результатов разработки продукта отсутствует.

Внедрение и сопровождение

Процесс внедрения, а также последующего сопровождения прикладных систем, как правило, состоит из следующих видов деятельности (Рисунок 5):

Установка ПО;

Обучение пользователей;

Сбор замечаний;

Устранение замечаний;

Модернизация ПО.

Рисунок 5. Виды деятельности при внедрении и сопровождении

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

В таблице 7 приведены сводные данные по ролям и функциям.

Таблица 7.Сводная таблица ролей и функций

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

2.2 Проблемы и задачи

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

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

Основными задачами в части реорганизации бизнес-процессов является:

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

Определение типа процесса для сопровождения существующих проектов;

Выработка стандарта планирования новых проектов и сопровождения существующих проектов;

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

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

2.3 Анализ типовых вариантов процессов разработки

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

На рисунке 6 приведен водопадный процесс разработки с указанием результатов на каждом этапе.

Рисунок 6. Водопадный процесс разработки

Спиральный процесс

В случае спирального процесса последовательность «анализ - проектирование - реализация - тестирование» выполняется несколько раз. Основные причины использования спирального процесса обычно следующие:

- необходимость предупреждения рисков;

- необходимость предоставить заказчику частичную версию проекта до его завершения.

Основной трудностью использования спирального процесса является поддержка актуальности документации.

На рисунке 7 приведен спиральный процесс разработки.

Рисунок 7. Спиральный процесс разработки

Инкрементальный процесс

Инкрементальный процесс разработки представляет собой постоянное продвижение проекта понемногу вперед при практически непрерывном процессе. Это аналог спирального процесса с небольшим временным интервалом полного цикла (например, неделя). Данный процесс очень удобен на стадии сопровождения проекта. Однако использование данного процесса предполагает очень четкое управление документацией в силу постоянного обновления.

Унифицированный процесс

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

На рисунке 8 приведен унифицированный процесс разработки.

Рисунок 8. Унифицированный процесс разработки

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

Для разработки новых проектов - унифицированного процесса разработки;

Для сопровождения - использование инкрементального процесса.

2.4 Оптимизация процессов разработки и сопровождения

При переходе к проектному управлению необходима реорганизация бизнес-процессов в соответствии с жизненным циклом реализации проектов. Жизненный цикл проекта - это комбинация процессов и подпроцессов, необходимых для создания (реализации) объекта или решения. Так, жизненный цикл проекта в стандарте PMI (Project Management Institute, США) состоит из следующих фаз:

Начальная фаза (инициирование проекта);

Разработка;

Реализация;

Завершение.

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

Фазы могут обладать следующими характеристиками:

Границы;

Вход, выход;

Длительность;

Операции;

Участники;

Бюджеты.

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

Процесс инициирования - принятие решения о начале выполнения проекта;

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

Процесс исполнения - координация людей и других ресурсов для выполнения плана;

Процесс анализа - определение соответствия плана и исполнения проекта поставленным целям и критериям и принятие решения о корректирующих воздействиях;

Процесс управления - определение корректирующих воздействий, их согласование, утверждение и применение;

Процесс завершения - формализация выполнения проекта и приведение его к упорядоченному финалу.

Процессы управления проектами приведены на рисунке 9.

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

Каждый этап управления обладает следующими характеристиками:

Границы;

Документы на входе, документы на выходе;

Временной регламент;

Операции;

Участники.

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

Рассмотрение управления потоком проектов с позиции общих корпоративных целей компании;

Ведение систематизированного реестра проектов, позиционирование проектов по классификаторам реестра, задание типологии основных групп проектов;

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

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

Использование возможностей мультипроектного управления ресурсами, составление балансов по ограниченным ресурсам;

Формирование и использование корпоративной мультипроектной базы данных;

Формализация, накопление и анализ опыта реализации проектов и непрерывное совершенствование корпоративных стандартов их выполнения (технологии, процедуры, организационные структуры, бизнес-процессы), построение менеджмента, основанного на знаниях;

Бюджетирование проектов, включение бюджета проектов в основной бюджет компании.

В рамках данной работы рассматриваются две группы процессов:

Проекты по разработке новых прикладных систем;

Проекты по сопровождению существующих систем.

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

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

3.1 Описание бизнес-процессов «как должно быть

Жизненный цикл нового проекта представлен на диаграмме деятельности (Рисунок 10).

Рисунок 10. Жизненный цикл нового проекта

Создание Устава проекта

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

Подобные документы

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

контрольная работа , добавлен 22.02.2017


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

лабораторная работа , добавлен 21.07.2015


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

контрольная работа , добавлен 15.09.2014


Понятие бизнес-моделирования. Анализ финансово-хозяйственной деятельности компании ЗАО "Ясень"; разработка бизнес-процессов производства, их оптимизация и повышение эффективности работы предприятия с внедрением программного продукта "1С:Молокозавод".

дипломная работа , добавлен 15.09.2012


Проектирование совокупности взаимосвязанных бизнес-процессов предприятия как трудоемкий процесс по их моделированию. Модели прямого и обратного реинжиниринга в рамках стандарта моделирования бизнес-процессов IDEF0 на примере компании Destiny Development.

курсовая работа , добавлен 22.04.2014


Управление бизнес-процессами как часть стратегии компании. Автоматизация бизнес-процесса посредством внесения дополнительных документов в информационную систему 1С: Предприятие, используемую для учета коммерческой деятельности по распределению товаров.

курсовая работа , добавлен 06.09.2015


Исследование политики стратегического развития компании "Аэрофлот". Характеристика организации, анализ макро-, микроокружения и внутренней среды. Карта стратегических групп, SWOT-анализ, цепочка ценностей М. Портера. Описание миссии и целей компании.

курсовая работа , добавлен 18.04.2014


Определение процессного подхода к управлению организацией. Моделирование бизнес-процессов; объекты и связи в IDEF0, преимущества и недостатки их использования. Процессно-организационная бизнес-модель компании ОАО "Урал"; паспорт процесса "Продажа".

курсовая работа , добавлен 03.05.2014


Повышение конкурентоспособности компании за счет предоставления высококачественных услуг, ориентированных на клиента, - миссия компаний ООО "Астор". Цели компании, показатели их достижения. Анализ бизнес-процессов организации, характеристика работ.

отчет по практике , добавлен 21.12.2013


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

Данная аттестационная работа направлена на описание и оптимизацию бизнес-процессов компании-разработчика программного обеспечения (далее – ПО).

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

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

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

Стратегический анализ деятельности компании;

Описание текущего положения и штатной структуры компании;

Описание существующих бизнес-процессов;

Анализ и оптимизация бизнес-процессов, выработка рекомендаций по их изменению, регламентирование деятельности;

Оптимизация штатной структуры компании;

Анализ проблем и выработка решений по управленческим и кадровым проблемам компании;

Создание образцов типовых документов;

Определение перспективных направлений автоматизации деятельности.

1.Стратегический анализ деятельности компании

1.1 Обоснование выбора организации

ВкачествеисследуемойорганизациивыбранаООО«Кварта».

Основными направлениями деятельности компании являются:

Разработка программного обеспечения (ПО);

Внедрение и сопровождение программного обеспечения;

Поставка аппаратного обеспечения;

Техническая поддержка.

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

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

Организационно-штатная структура компании еще больше усугубляет вышеуказанные проблемы.

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

Описание организации приведено в Таблице 1.

Таблица 1.Описание организации как объекта управления

Параметр описания	Характеристика
Название, местонахождение	ООО «Кварта», г. Москва
Назначение	Оказание услуг автоматизации для федеральных и территориальных органов государственной власти, бюджетных учреждений, а также для малых и средних предприятий (разработчик и поставщик услуг по внедрению и сопровождению автоматизированных информационных систем (АИС), системная интеграция)
Отраслевая принадлежность	Отрасли третичного цикла Частная фирма Информационные технологии
Правовая форма и вид собственности	Коммерческое предприятие, общество с ограниченной ответственностью, частное
Историческая справка	Образовалась в 1993 году. Первый заказчик Управление делами Президента РФ Начало создания финансово-бухгалтерской системы, организация ЛВС. Постепенно в компании образовался ряд направлений деятельности, которые впоследствии переросли в отдельные компании («Кварта-технологии», «Кварта-сети», «Кварта-консалтинг», Кадровое агентство «Кварта», «Сенсорные системы» и др.). Непосредственно сама компания занялась разработкой интегрированных информационных систем управления предприятием (ИИС), а также комплексной автоматизацией организаций и предприятий. Основным направлением деятельности были выбраны федеральные органы законодательной и исполнительной власти РФ. На данный момент заказчиками услуг компании являются Аппарат Правительства, Государственная Дума, Совет Федерации, Счётная палата, УД Президента РФ и большая часть Министерств, федеральных служб и агентств, включая подведомственные организации и загранучреждения, а также коммерческие организации различных форм собственности. Список предоставляемых услуг постоянно растёт, появляются новые продукты. В планах компании расширить влияние в секторе муниципальных образований и продвижение в регионы. Также компания постепенно расширяет деятельность в секторе коммерческих предприятий.
Организационная структура	См. ниже (Модель «Цепочки ценностей»)
Структура управления	В данный момент компания использует вертикальную систему управления от генерального директора к руководителям структурных подразделений (департаментов), часть из которых выполняет функции заместителей, далее к начальникам отделов и групп. Подразделения поделены по функциональному признаку. В последнее время в связи с большим количеством разнородных проектов, требующих специалистов разных направлений, постепенно вводится практика назначения руководителей проектов (как правило руководители отделов) и планируется серьёзная структурная реорганизация.
Параметр описания	Характеристика
Ресурсы	Основной ресурс – сотрудники. Поощрение инициативных сотрудников, дружеская атмосфера в коллективе. Большое внимание уделяется обучению. Репутация в секторе разработки ПО для федеральных органов, рекомендации клиентов. Накопленный опыт, знание до тонкостей специфики работы в данном секторе. Многолетний опыт работы и большое количество завершенных проектов, что позволяет участвовать и выигрывать конкурсы. Технические ресурсы: помещения, коммуникации (телефония, широкополосный доступ в Интернет), вычислительная техника, транспорт.
Культура	Высокая мотивация сотрудников, преданность фирме, устоявшийся коллектив, дружественные отношения в коллективе, знание целей и перспектив.
Ключевые факторы внешней среды	Законодательство: Изменчивое законодательство, постоянные нововведения, часто не подкреплённые методическими рекомендациями, ограниченное время на реализацию изменений. Заказчики: Специфика данного рынка (федеральные органы власти) в том, что на процесс разработки / внедрения дается очень мало времени. Часто через несколько дней после подписания контракта система должна полностью функционировать и быть наполненной информацией. Многое делается по принципу «надо вчера». Как правило, отсутствие единых стандартов, руководство заказчиков часто дает противоречивые указания, диктует собственные условия, часто расходящиеся с реальностью. Ограниченное, часто запаздывающее финансирование. Как правило, платформы для приложений определены заранее, поэтому необходим большой арсенал версий под разные платформы. Конкуренция: Конкуренция высокая, как правило, выигрывает не лучший продукт или предложение, а лучшая протекция со стороны заказчика. Каждый руководитель имеет свои устоявшиеся связи и поставщиков, поэтому часто борьба идет не за конкурентные преимущества, а за протекцию. Новые игроки как правило отсутствуют, конкурируют как правило компании с устоявшейся клиентской базой, по причине того, что в данном сегменте требуется большой опыт и специфическое отношение к заказчикам. Технологии: сильная зависимость от тенденций развития технологий, необходимость следовать за тенденциями рынка, плюс необходимость поддержки большинства актуальных технологий.
Руководство	Генеральный директор, он же собственник: оперативное управление деятельностью компании, консолидированная стратегия, участие в переговорах с ключевыми заказчиками. Также в данный момент есть 3 заместителя, они же являются руководителями основных департаментов компании. Каждый ведет свой круг вопросов в рамках департамента, выработку стратегии своего направления, переговоры и пр. и осуществляет координацию с другими подразделениями.
Параметр описания	Характеристика
Модель «Цепочки ценностей»	Процессы основной деятельности: Разработка: выпуск качественных и функциональных продуктов с максимальным функционалом, необходимым заказчику. Следование новым технологиям и поддержка большого количества платформ. Интеграция: полный комплекс услуг, начиная с этапа сбора информации и проектирования, до сдачи в эксплуатации функционирующих в соответствии с требованиями заказчика программно-аппаратных комплексов Сопровождение: ключевой особенностью является постоянная поддержка систем у заказчика. Компания никогда не оставляет заказчиков один на один с информационной системой. Как правило при необходимости у заказчика присутствуют сотрудники компании, часто выделяются постоянные представители. Это позволяет существенно улучшить быстроту и качество обслуживания. Поставки: поставка любых аппаратно-программных продуктов различных производителей, настройка, адаптация, ввод в эксплуатацию. Широкие партнёрские отношения с производителями. Предоставление услуг: также компания специализируется на предоставлении услуг по обслуживанию компаний, с уже работающей аппаратно-программной инфраструктурой, осуществляет, разрабатывает заказные продукты. Поиск заказчиков: мониторинг проводимых конкурсов, выбор оптимальных предложений, подготовка конкурсной документации, участие в конкурсах, итоговая документация Процессы вспомогательной деятельности: Разработка систем для внутреннего пользования Поддержка программно-аппаратной части компании Управление персоналом (мотивация, обучение и пр.) Снабжение Внутренний финансово-бухгалтерский учёт Технологические исследования Делопроизводство

1.2 Организационно-штатная структура

Существующая штатная структура организации приведена на Рисунке 1.

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

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

Кадровая служба не существует в виде отдельного подразделения.

Рисунок 1. Существующая штатная структура.

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

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

1.3 Основные проблемы управления

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

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

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

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

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

Отсутствие планирования. Часто приводит к авральному выполнению проектов и нехватке сотрудников.

Слаборазвитая система отчётов и документирования проектов. Это влечёт за собой недостаточную информированность, а иногда даже частичную незаменимость сотрудника, участвовавшего в конкретном проекте

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

1.4 Постановка стратегических целей

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

Миссия

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

Стратегический профиль

Текущую стратегию я бы сформулировал следующим образом:

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

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

Видение (стратегическое намерение)

1. Какой мы хотим видеть свою организацию в будущем?

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

2. Что из себя представляет наш бизнес сейчас и каким он будет в будущем?

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

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

3. Кто является потребителями нашей продукции (услуг) и на какую группу покупателей организация будет ориентироваться в будущем?

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

4. Какими способами мы собираемся увеличивать ценность нашей продукции для потребителей?

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

Стратегические цели

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

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

2. Генеральная цель.

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

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

Завершить реорганизацию структуры (создание новых структурных подразделений и распределение функций между ними)

Выделение в отдельную структуру аналитиков и проектировщиков.

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

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

Создать систему обучения вновь принятых сотрудников

Внедрить систему аттестации сотрудников

Организовать процесс повышения профессиональной подготовки кадров

Проведение тематических семинаров

Формализовать процессы.

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

Перейти к грамотной, качественной и формализованной постановке задач

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

Стандартизировать процессы планирования и отчётности

1.5 Анализ и выбор стратегии

Результаты SWOT-анализа приведены в таблице 2 и таблице 3.

Таблица 2.Анализ факторов, воздействующих на достижение стратегических целей

Факторы	Шифр	Содержание	Оценка
Сильные стороны организации	S1		7
	S2		6
	S3		8
	S4		9
Итого	30
Слабые стороны организации	W1		7
	W2	Низкий уровень менеджмента организации, структура, не отвечающая текущим требованиям	8
	W3		6
Итого	21
Возможности окружающей среды	O1		7
	O2		9
	O3	Увеличение финансирования по программе «Электронная Россия», рост ИТ-рынка в целом	8
Итого	24
Угрозы окружающей среды	T1		4
	T2		6
	T3		8
Итого	18

Таблица 3.Итоговая стратегическая матрица

Сильные стороны организации				Слабые стороны организации
S1	S2	S3	S4	W1	W2	W3
Возможности	S3-O2 Увеличение объемов поставок решений заказчикам S4-O3 Рост количества клиентов S1-O3 Расширение линейки продуктов S3-O1 Практически монополия по ряду поставляемых задач S2-O2 Возможность работы в кредит S4-O1 Возможность получения дополнительных разрешений S2-O1 Возможность выпускать продукты с соотв. с самыми современными технологиями				W1-O3 Использовать средства для модернизации линейки продуктов, вкладывать в новые технологии W3-O2 Возможность планирования работ заранее, оптимальное использование ресурсов W1-O1 Использование партнёрской поддержки для скорейшего освоения последних технологий W2-O3 Реорганизация системы управления, поиск профессиональных кадров
O1
O2
O3
Угрозы	S1-T1 Возможность текучки кадров. Повышать заинтересованность, постоянный мониторинг. S2-T1 Не терять финансовую независимость, что позволит существовать в кризисные моменты достаточно продолжительное время, предоставлять возможность работы в кредит S3-T3 Постоянно отслеживать изменение технологий, заниматься перспективными разработками. S2-T2 выпускать новый продукт раньше, чем конкуренты				W1-T3(Т1) Как можно скорее перейти на более совершенную платформу W3-T1(Т2) Отслеживать состояние рынка, тщательно планировать деятельность W2-T2 Привести структуру в соответствие с возникшей необходимостью, повышать квалификацию менеджеров
T1
T2
T3
T4

Граф типовых стратегий организации приведен на рисунке 2.

Рисунок 2. Граф типовых стратегий

Выбор и обоснование стратегии

В таблице 4 приведен выбор и оценка факторов, задействованных в трёх базовых стратегиях.

Таблица 4.Выбор и оценка факторов, задействованных в трёх базовых стратегиях

Факторы	Оценка	Реструктуризация (лидерство по издержкам)		Дифференциация		Комбинированная стратегия
		Удельный вес фактора		Удельный вес фактора	Средне-взвешенная оценка фактора	Удельный вес фактора	Средне-взвешенная оценка фактора
S1	7	0,1	0,7	0,1	0,7	0,1	0,7
S2	6	0,15	0,9	0,2	1,2	0,18	1,08
S3	8	0,1	0,8	0,25	2	0,17	1,36
S4	9	0,15	1,35	0,25	2,25	0,2	1,8
W1	7	0,15	1,05	0,05	0,35	0,1	0,7
W2	8	0,15	1,3	0,1	0,8	0,12	0,96
W3	6	0,2	1,2	0,05	0,3	0,13	0,78
Итого	1	7,3	1	7,6	1	7,38
O1	7	0,15	1,05	0,2	1,4	0,17	1,19
O2	9	0,15	1,35	0,2	1,8	0,17	1,53
O3	8	0,15	1,2	0,25	2	0,2	1,6
T1	4	0,2	0,8	0,05	0,2	0,13	0,52
17T2	6	0,2	1,2	0,15	0,9	0,18	1,08
T3	8	0,15	1,2	0,15	1,2	0,15	1,2
Итого	1	6,8	1	7,5	1	7,12

По сумме оценок:

По сумме оценок наилучшей стратегией является стратегия дифференциации.

По реальности задействованных факторов:

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

Выбранная стратегия

Возможные действия в рамках реализации стратегии:

Совершенствование и расширение линейки продуктов

Повышение профессионального уровня сотрудников

Повышение значимости планирования.

Агрессивная маркетинговая политика расширение партнёрских отношений.

Возможные последствия реализации выбранной стратегии

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

К недостаткам можно отнести следующее:

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

Надо очень серьёзно прорабатывать данные вопросы во избежание негативного влияния.

Реализация системы планов. Эффективность изменений

Определение необходимых изменений приводится в таблице 5.

Таблица 5.Определение необходимых изменений

Шифр	Наименование	Вес	7S	Реакция
S1	Сплоченный, высокопрофессиональный коллектив.	0,8	Shared Values	Держать уровень оплаты труда на рыночном уровне, предоставлять бонусы и гарантии. Разработать программы мотивации и повышения квалификации персонала, ввести аттестацию.
S2	Хорошая технологическая база, финансовая независимость	0,7	Skills	Технологическая база должна соответствовать современному уровню, обновлять при необходимости, использовать имеющиеся возможности для привлечения перспективных клиентов (кредит…)
S3	Актуальные инновационные разработки, учитывающие специфику рынка	1,4	Skills	Поддерживать высокое качество продуктов, уделять больше внимания заказчикам. Донести до потенциальных заказчиков преимущества (маркетинговая программа), всегда быть в курсе последних изменений, выводить на рынок продукты раньше конкурентов.
S4	Отличная репутация и долгов время пребывания на рынке	1,7
W1	Две линейки однородных продуктов, одна из которых использует устаревшую платформу	0,7		Отказаться от разработки двух линеек продуктов, перевести их на единую интегрированную платформу, сделать продукт современным и качественным. Постоянно проводить инновационные исследования и создать непрерывный цикл периодических обновлений.
W2	Низкий уровень менеджмента организации, структура не отвечающая текущим требований	1,2		Реорганизация структуры компании, формализация процессов, ввод в эксплуатацию внутренней информационной системы и рамках неё систем планирования, отчётности и пр. Обучение руководящего состава, привлечение новых кадров.
W3	Отсутствие маркетинговой политики и долгосрочного планирования	1		Разработка маркетинговой стратегии. Выработка стратегических планов и направлений развития компании на основе имеющихся знаний и возможностей.
O1	Наличие лицензий и разрешений соответствующих органов, партнёрство с поставщиками СУБД и системного ПО	1,4	Skills	Развивать партнёрские отношения с поставщиками. Лицензировать деятельность и обеспечивать наличие разрешений во всех требуемых направлениях.
O2	Наличие действующих контрактов, необходимых связей, владение необходимой информацией	1,7		Обеспечивать качественное выполнение контрактов с целью их продления, расширения услуг и повышения репутации. Расширять связи с целью своевременного получения информации.
O3	Увеличение финансирования по программе «Электронная Россия», рост ИТ рынка в целом	1,6		Развивать маркетинговую политику, активно участвовать в конкурсах, предлагать качественные, функциональные, опережающие конкурентов продукты
T1	Снижение финансирования госсектора, финансовые потрясения	1,2		Иметь резервные фонды и возможность предоставления услуг в кредит, широкий спектр продуктов и услуг. Поддерживать коллективный дух и корпоративные ценности.
T2	Риск активизации текущих игроков рынка	0,7	Strategy	Вести активный мониторинг рынка. Владеть информацией. Иметь широкую продуктовую линейку с сильными конкурентными преимуществами.
T3	Зависимость от тенденций рынка в области платформ разработки	1		Активно сотрудничать с поставщиками, развивать партнёрские отношения. Повышать профессиональный уровень сотрудников, заниматься инновационными разработками.

Разработка мероприятий, программ и планов

Планирование

1. Создание плана реорганизации.

2. Планирование рабочего времени сотрудников.

3. Создание маркетингового плана

4. Создание плана обучения и переподготовки персонала

Организация

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

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

2. Разработка всех технических регламентов и формализация процессов.

3. Написание детальных должностных инструкций

4. Детальное распределение полномочий и распределение проектов. Назначение ответственного за результат.

Мотивация

В таблице 6 приводятся показатели качества трудовой жизни.

Таблица 6.Показатели качества трудовой жизни

Показатель	Положение в данный момент
Справедливая заработная плата
Рыночная оплата труда	Присутствует (но ближе к нижней планке). Есть институт премирования по итогам года и завешенных проектов, но носит субъективный характер.
Обоснованная дифференциация оплаты труда	В зависимости от должности
Индивидуальная ответственность за результаты общего труда	Присутствует, начиная со среднего уровня, но никоим образом не отражается в оплате труда
Доп. вознаграждение за длительный стаж работы в компании	Фактически отсутствует
Программа дополнительных выплат
Выплата работнику и его семье в случае болезни	да, по базовой ставке оплаты труда
Оплачиваемое время отпуска в связи с праздниками и отпусками	да, в соответствии с КЗОТ
Оплачиваемые отпуска для дополнительного образования	Оплачиваются в случае, если обучение происходит по направлению фирмы
Условия безопасности труда и охраны здоровья	на уровне «здравого смысла»: все используемое оборудование в работе соответствует международным стандартам безопасности, офисные площади планируются из рекомендованных санитарных норм.
Гарантия занятости
Обеспечение непрерывности трудового стажа	да, в соответствии с КЗОТ
Уверенность работников в своем будущем	Да, стабильная компания, 15 лет на рыке.
Развитие способностей работников	Обучение происходит стихийно или по необходимости.
Социальная интеграция
Социально-психологический микроклимат в организации	Нейтральный. Много как позитивных, так и негативных моментов. Присутствует некая обособленность структурных единиц.
Отношение руководства и подчиненных	Между руководителями подразделений и подчиненными- ближе к демократическому.
Участие работников в управлении производством и собственностью, поощрение инициатив и новых идей	1. Поощрение инициативности сотрудников и внедрение их идей зависит в большинстве случаев от руководителей структурных единиц и их видения ситуации. Т.е. в некоторых подразделениях это поощряется, в некоторых игнорируется и исключается. 2. Управление собственностью: скорее исключает участие сотрудников в качестве партнеров по бизнесу.

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

Контроль

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

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

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

Оценка эффективности предлагаемых изменений

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

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

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

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

2.Анализ и оптимизация бизнес-процессов

2.1 Описание бизнес-процессов «как есть»

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

Разработка

Процесс разработки новых прикладных систем, как правило, состоит из следующих видов деятельности (Рисунок 3):

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

Разработка;

Тестирование;

Документирование.

Процесс перехода между итерациями

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

В результате завершения итерации в хранилище данных по проекту, доступном всем заинтересованным лицам, должны находиться следующие данные:

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

Описание функциональности, добавленной по сравнению с предыдущей версией;

Пронумерованные версии всех проектных документов на момент завершения итерации.

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

Процесс перехода продукта из разработки во внедрение и сопровождение

При передаче продукта из разработки во внедрение и дальнейшее сопровождение руководитель проекта (при его отсутствии – руководитель подразделения, ответственного за внедрение) составляет план внутренней приемки продукта, в котором должны быть отражены следующие этапы:

Ознакомление с проектной документацией;

Демонстрация программного продукта;

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

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

Оценка деятельности

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

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

Документ «Ведомость замечаний» свидетельствует о наличии вопросов и замечаний со стороны исполнителей какой-либо стадии к результатам предыдущей стадии. Чаще всего это также свидетельствует о низком качестве результатов, реже – о недостаточной квалификации исполнителей текущей стадии.

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

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

3.2 Изменения в организационно-штатной структуре

Изменения в организационно-штатной структуре представлены на рисунке 14.

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

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

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

Все подразделения, ответственные за внедрение и сопровождение, объединяются в Департамент сопровождения.

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

Также отдельно выделен Департамент профессионального развития персонала.

Рисунок 14. Новая организационно-штатная структура

3.3 Регламентирование деятельности

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

Регламентированию подверглись в первую очередь следующие процессы:

Оперативный мониторинг и информационная поддержка хода исполнения контрактных обязательств (Регламент приведен в Приложении 2);

Разработка программного обеспечения и выпуск дистрибутивов (Регламент приведен в Приложении 3);

Исполнение заявок на обслуживание и сопровождение (Регламент приведен в Приложении 4).

Регламенты являются определяющими документами при выполнении указанных процессов.

Помимо регламентов, были разработаны типовые должностные инструкции (образец приведен в Приложении 5), а также квалификационные требования к сотрудникам компании (образец приведен в Приложении 6), что позволит упорядочить и организовать процессы, связанные с движением кадров в компании.

3.4 Перспективные направления автоматизации

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

Приоритетными являются нижеуказанные направления.

Информационная поддержка исполнения контрактных обязательств:

Учетные сведения о клиентах;

Реестр контрактов;

Документационное обеспечение контрактных обязательств (контракты, дополнительные соглашения, календарные планы, акты, счета, отчеты и прочая документация).

Кадровый учет:

Штатная структура компании;

Личные карточки сотрудников;

Приказы о назначении, увольнении, отпусках и пр.;

Табельный учет.

Делопроизводство и документооборот:

Входящая и исходящая корреспонденция;

Создание, согласование и утверждение внутренней документации;

Поддержка управления версиями документов.

Информационная поддержка процессов выпуска дистрибутивов и обновлений:

Учет дистрибутивов и стадий их выпуска;

Учет замечаний, реализованных в дистрибутиве;

Учет разовых обновлений;

Учет установленных у клиентов версий дистрибутивов.

Информационная поддержка процессов разработки, внедрения, сопровождения, технической поддержки:

Планирование деятельности;

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

З аключение

Поставленная задача оптимизации бизнес-процессов была решена в полном объеме; оптимизации подверглись основные процессы деятельности организации, а именно разработка, внедрение и сопровождение программного обеспечения.

Осуществлен переход от функционально-ориентированной к проектно-ориентированной штатной структуре компании.

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

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

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

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

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

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

Список использованной литературы

1.Амблер С. Гибкие технологии: экстремальное программирование и унифицированный процесс разработки. Библиотека программиста. СПб.: Питер, 2005.

2.Бек К. Экстремальное программирование. СПб.: Питер, 2002.

3.Браудэ Э. Технология разработки программного обеспечения. СПб.: Питер, 2004.

4.Даешь инжиниринг! М.: Издательство Эксмо, 2005.

5.Константайн Л., Локвуд Л. Разработка программного обеспечения. СПб.: Питер, 2004.

6.Крачтен, Филипп. Введение в Rational Unified Process. 2-е изд. М.: Издательский дом «Вильямс», 2002.

7.Кролл П., Крачтен Ф. Rational Unified Process – это легко. Руководство по RUP. М.: КУДИЦ-ОБРАЗ, 2004.

8.Липунцов Ю.П. Управление процессами. Методы управления предприятием с использованием информационных технологий. М.: Компания АйТи, 2003.

9.Хэлдман Ким. Управление проектами. М.: ДМК Пресс; Академия АйТи, 2007.

П риложение 1

Образцы внутренних документов

Структура документа «Постановка задачи»

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

1. Основные сведения

Название проекта, модуль

Название функциональности

Основания для разработки (контракт, пользователь, законодательство, и пр.)

Необходимость распространения на другие проекты

2. Описание назначения

3. Варианты использования

a. Название варианта использования, текстовое описание, UML-схема

b. Название варианта использования, текстовое описание, UML-схема

4. Диаграммы потоков данных

при необходимости

5. Диаграммы переходов состояний

при необходимости

6. Диаграммы классов

при необходимости

7. Проект пользовательского интерфейса

8. Ограничения

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

Структура документа «Заявка»

1. Основные сведения

Название проекта, модуль

Основания для разработки

2. Описание заявки

Текстовое описание содержания заявки, при необходимости – ссылки на скриншоты (для ошибок – обязательно)

3. Скриншоты

Копии экранов с выделенными и пронумерованными блоками (для ссылок в текстовом описании)

Структура документа «Тестовый пример»

1. Основные сведения

Номер заявки (из внутренней системы)

Название проекта, модуль

Название функциональности

2. Тестовые примеры

o Входные параметры: «название» = «значение»

o Последовательность действий пользователя

o Выходные параметры: «название» = «значение»

Структура документа «Описание реализации»

1. Основные сведения

Название проекта, модуль

Название функциональности

2. Описание алгоритма

Общее описание выбранных методов решения задачи

3. Реализация вариантов использования (если были указаны в «Постановке задачи»)

a. Название варианта использования, алгоритм реализации

4. Описание системных изменений

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

o все входные и выходные параметры, а также используемые внутри переменные должны иметь описание назначения;

o код должен быть разбит на логические блоки (при их наличии), снабженные комментариями об их назначении;

o при каждом изменении в начале после описания назначения должен вставляться комментарий с датой, автором и описанием изменения.

b. видимо, в основном для ИИС – перечень измененных классов, гридов, и пр.

5. Описание интерфейсных изменений

при изменении форм – скриншоты «что было» - «что стало» с выделением изменений

при добавлении форм – скриншоты этих форм

6. Диаграммы классов

при необходимости, видимо, в основном для ИИС

Структура документа «Краткое руководство»

Документ «Краткое руководство» составляется в свободном стиле, при этом он должен отражать описание всех вариантов использования, реализованных для требования.

Структура документа «Отчет о тестировании»

Данный документ составляется на основании «Программы и методики испытаний» либо «Тестового примера».

1. Основные сведения

Номер заявки (из внутренней системы) – в случае выполнения разовой заявки

Название проекта, модуль

Название функциональности

Дата тестирования, номер цикла тестирования

Суммарные данные (% успешно пройденных тестов)

2. Тест 1: пройден/не пройден

Должно быть:

o Входные параметры: «название» = «значение»

o Последовательность действий пользователя

o Выходные параметры: «название» = «значение»

Получено:

o Выходные параметры: «название» = «значение»

Комментарии

3. Тест 2: пройден/не пройден

Структура документа «Ведомость замечаний»

«Ведомость замечаний» составляется в двух случаях:

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

2. При внедрении и сопровождении системы.

Структура документа является следующей:

1. Основные сведения

Название проекта

Дата составления, последовательный номер, автор

2. Таблица замечаний

№ п/п

Замечание

Cрочняк нужно выполнить ответы на вопросы по информатике за 1 день, тема "Проектный практикум"

Проектный практикум Задание 1 Описание компании разработчика 1. Придумайте фирму, занимающуюся разработкой программного обеспечения. Определите: a. Название, количество персонала, b. Сферу деятельности, комплекс услуг, c. Миссию, d. Видение. 2. Разработайте организационную структуру фирмы: a. Создайте схему организационной структуры фирмы, b. Опишите бизнес - цели и задачи всех подразделений фирмы, c. Опишите состав персонала каждого подразделения и их функциональные обязанности, 3. Разработайте методологию создания программных продуктов в фирме: a. Выберите модель жизненного цикла и стандарт, в соответствие с которым будет проводиться разработка проекта по созданию ПО. b. Определите фазы жизненного цикла проекта. 4. Опишите технологию создания команды проекта по разработке ПО для заказчика: a. организационную структуру проекта b. состав команды проекта, c. создайте матрицу ответственности по проекту. Отчетный документ «Описание фирмы» оформить в Word, отчет должен быть понятным и наглядным. Проектный практикум Задание 2 Разработка концепции проекта 1. Выберите компанию, работающую в определенной сфере бизнеса (кроме сферы IT). 2. Опишите компанию (название, численность работников, сферу деятельности, цели, управляющий аппарат). 3. Сформулируйте проблемы, стоящие перед компанией и обоснуйте необходимость реализации проекта по разработке и внедрению ИС. 4. Разработайте концепцию проекта создания ИС. Для создания концепции используйте шаблон документа с пояснениями, а также материал лекций С.Архипенкова (Архипенков С. Лекции по управлению проектами// http://arkhipenkov.ru/index.files/publications.htm.- С.42-56) Шаблон Концепции проекта Итеративный подход к процессу разработки требует использования гибкого способа ведения документации. Живые документы должны изменяться по мере эволюции проекта. На фазе выработки концепции планы имеют форму описания высокоуровневых подходов и по мере подготовки распространяются среди членов проектной группы и других заинтересованных лиц для получения отзывов. После перехода к фазе планирования документы постепенно дорабатываются, возникающие детальные планы снова поступают на проверку всем заинтересованным сторонам, и описанный процесс повторяется итеративно. Типы планов и общее количество описывающих их документов могут варьироваться от проекта к проекту. 1. Необходимость проекта Обоснование необходимости Сформулируйте, на разрешение каких проблем и/или удовлетворение каких потребностей заинтересованных сторон направлен проект. Видение проекта Видение – это ничем не ограничиваемое представление о том, каким должно быть решение. Видение проекта направлено на формирование у всех вовлеченных в проект сторон единого понимания его концепции. Формулировка видения должна быть достаточно краткой для запоминания, достаточно ясной для понимания и достаточно сильной для мотивирования. Хорошая формулировка видения ориентируется на пять SMART характеристик:  Specific (определенность/конкретность) – видение четко указывает на то (идеальное) состояние, достижение которого является целью проекта.  Measurable (измеримость) – дает проектной группе четкий критерий успешности проекта и достижения поставленных целей.  Achievable (достижимость) – цели, сформулированные в видении, должны быть достижимы в рамках имеющихся ресурсов, времени и возможностей команды. Достижимость мотивирует команду на выполнение проекта.  Relevant (обоснованность) – цели, сформулированные в видении, должны иметь существенное значение для заинтересованных сторон и напрямую быть связанными с их проблемами и/или потребностями.  Time-based (ограниченность во времени) – видение должно четко указывать на ожидаемые временные рамки, в которые решение будет достигнуто. Сформулируйте (максимально кратко, в одной двух фразах) видение проекта. Анализ выгод Основываясь на сформулированном выше видении проекта, перечислите, какие выгоды получат заинтересованные стороны по завершении проекта (в результате внедрения и использования решения). 1. Концепция решения Концепция решения предоставляет общее описание подходов, которые проектная группа предполагает использовать для разрешения проблем и/или удовлетворения потребностей заинтересованных сторон. Цели и Задачи Формирование концепции решения начинается с выяснения у заинтересованных сторон, описания и фиксации проектной группой целей проекта. Далее каждая цель разбивается на измеримые компоненты – задачи. Во взаимодействии с заинтересованными сторонами проекта сформулируйте и утвердите цели решения, на достижение которых направлен проект. Определите задачи, из которых будет складываться достижение каждой цели. Предположения и Ограничения В процессе формирования концепции решения проектная группа постоянно взаимодействует с заинтересованными сторонами, собирая необходимую информацию о требованиях к функциональности будущего решения. Тем не менее, неизбежная неполнота информации приводит к тому, что относительно некоторых функциональных возможностей решения могут потребоваться предположения. Помимо функциональных требований заинтересованные стороны могут выдвигать качественные требования, задающие ограничения на создаваемое решение. Также ограничения могут порождаться средой, в которой должно будет функционировать решение после внедрения. Определите, имеются ли в проекте требования, нуждающиеся в предположениях, если да, сформулируйте их. Определите, имеются ли ограничения на будущее решение. Если да, сформулируйте их. Анализ использования Основой формулировки требований является анализ использования, включающий определение пользователей и описание того, как пользователи будут взаимодействовать с решением. Пользователи В разработке решения заинтересованы множество сторон, однако непосредственная работа с ним будет выполняться пользователями, поэтому прежде чем приступать к дизайну решения, необходимо определить, кто будет с ним взаимодействовать. В процессе анализа должны быть выделены группы пользователей (например, на основе областей их деятельности, в которых будет использоваться разрабатываемое решение). Сформируйте список групп пользователей, для которых предназначено решение. Сценарии использования Сценарии использования определяют последовательности действий, которые пользователи выполняют при взаимодействии с решением. Один из возможных (и достаточно распространенных) вариантов описания сценариев использования – язык UML. Для каждой выделенной на предыдущем шаге группы пользователей определите характерные способы их взаимодействия с решением и, используя необходимые диаграммы UML, опишите сценарии использования. Требования Требования определяют, что должно делать разрабатываемое решение. Требования могут выражаться в терминах функциональности или в виде правил и параметров, определяющих функциональность. Требования пользователей Сформулируйте требования к решению с точки зрения пользователей. Системные требования Сформулируйте требования к решению с точки зрения среды, в которой оно должно будет функционировать после внедрения. 1. Рамки Рамки определяют пространство параметров, в котором будет создаваться решение, детализируя функциональность, определяя, что останется за рамками решения и указывая критерии, по которым заинтересованные лица будут судить о готовности решения. Рамки создаются на основе единого видения, являются результатом компромисса между сформулированными целями и условиями реальности и отражают приоритезацию заказчиком имеющихся требований к создаваемому решению. Частью процесса определения рамок проекта является вынесение менее важной функциональности из текущего проекта в планы на будущее. Рамки решения определяют функциональность решения и его возможности (включая те, что не относятся к программному обеспечению). Возможность (функциональность, составляющая, feature) – это требуемый или желаемый аспект программного или аппаратного обеспечения. Например, предварительный просмотр перед печатью может быть возможностью текстового процессора. Сопроводительные руководства пользователей, интерактивные файлы помощи, операционные руководства и обучение также могут быть составляющими решения. Рамки проекта определяют объем работ, который должен быть выполнен проектной группой для поставки заказчику каждого из элементов, определенного рамками решения. Управление рамками проекта критично для его успеха. Советуют определять и фиксировать рамки решения и проекта, используя треугольник компромиссов и матрицу компромиссов проекта. Функциональность решения Укажите здесь функциональность в терминах возможностей (features) и функций (functions), которая будет реализована в разрабатываемом решении. За рамками решения Укажите здесь функциональность, которая имеется или предполагается в требованиях заинтересованных сторон, но не будет реализована в решении, и опишите причины вынесения данных возможностей и функций за рамки решения (используйте треугольник компромиссов). Критерии одобрения решения Сформулируйте здесь критерии, в соответствии с которыми заинтересованные стороны будут принимать готовность решения. 1. Стратегии дизайна решения Стратегия архитектурного дизайна На основе разработанного списка возможностей и функций формируется стратегия архитектурного дизайна, описывающая решение в целом. Она определяет компоненты решения и их взаимодействие. Отличный способ описания решения на этом этапе – использование иллюстрирующих диаграмм (например, UML). Сформируйте и опишите общий архитектурный проект решения. Стратегия технологического дизайна Разработка решения потребует использования определенных продуктов и технологий. Стратегия технологического дизайна описывает, какие технологии и продукты выбраны проектной группой в качестве средства реализации решения. Аргументировано опишите, какие технологические средства будут использованы в процессе работы над решением. Проектный практикум Задание 3 Разработка плана проекта 1. Создайте проект в программе Microsoft Project. При создании проекта руководствуйтесь выбранным стандартом разработки и моделью жизненного цикла ПО. 2. Разработайте календарный план проекта: a. определите состав решаемых задач на каждой фазе проекта, b. в каждой фазе определите конечную веху. Опишите артефакты, характеризующие каждую веху (документы, модели, схемы и т.п.). c. определите длительности задач, d. определите иерархическую структуру задач, e. установите связи между задачами, f. введите обобщающую (суммарную) задачу. Рекомендации к выполнению: Работа с Microsoft Project Создание нового проекта Начиная новый проект в Microsoft Project, можно ввести или начальную, или конечную дату проекта, но не обе. Рекомендуется вводить только начальную дату проекта, а конечная дата будет рассчитана в Microsoft Project после ввода и планирования задач. Если проект должен быть завершен к определенной дате, следует ввести только конечную дату проекта. В этом случае первоначальное планирование следует выполнять с конечной даты, чтобы определить дату, когда необходимо начать проект. Если известна наилучшая начальная дата и работа начата, более эффективно выполнять планирование с начальной даты. 1. Откройте Microsoft Project. 2. В меню Проект выберите команду Сведения о проекте. Введите или выберите начальную дату проекта и планирование от Даты начала проекта, нажмите кнопку OK. 3. Сохраните проект в своей папке, задав ему имя. Ввод ключевых сведений о проекте В каждом проекте содержится уникальный набор компонентов: цель проекта, определенные задачи, а также лица, их выполняющие. Чтобы помнить все важные сведения и их взаимосвязь, следует вводить данные о проекте и обращаться к ним при необходимости. 1. В меню Файл выберите команду Свойства и откройте вкладку Документ. 2. Введите сведения о проекте: имя, тему, автора, руководителя, учреждение – название учреждения. 3. Нажмите кнопку OK. Настройка календаря проекта Календарь проекта можно изменять, чтобы отражать рабочие дни и часы для каждого участника проекта. Стандартный календарь с понедельника по пятницу, с 9:00 до 18:00, с часовым обеденным перерывом. Можно определить и нерабочее время, например выходные или ночное время, а также специальные выходные дни, например праздники. 1. В меню Сервис выберите команду Изменить рабочее время 2. Выделите в календаре название дней с понедельника по четверг и установите для выбранных дат стандартное рабочее время (с 9.00 по.13.00 и с 14.00 по 18.00). Затем для пятницы выберите Нестандартное рабочее время и установите окончание работы в 17.00. 3. Выберите параметр нерабочее время для выходных дней (субботы и воскресенья), а также для рождественских праздников (с 30 декабря по 10 января следующего года) и остальных привычных праздников. 4. Нажмите кнопку OK. Ввод и организация списка задач Когда создан план проекта, его можно заполнить задачами. Сначала перечислите шаги (фазы), необходимые для достижения целей проекта. Проще всего начать с крупных частей работы, а затем поделить каждую часть на задачи с отдельными результатами. Обычный проект представляет собой набор связанных задач. Задача определяется объемом работы и конкретными результатами; она должна быть достаточно короткой, чтобы можно было регулярно отслеживать ее ход выполнения. Длительность задач обычно должна лежать в интервале от одного дня до двух недель. 1. В меню Вид выберите команду Диаграмма Ганта. 2. В поле Название задачи введите название задачи, нажмите Enter. При этом Microsoft Project вводит со знаком вопроса примерную длительность задачи, равную одному дню. 3. Введите все задачи плана проекта (в соответствие с п.7 технического задания – стадии и этапы разработки). Организация задач в логическую структуру Структурирование помогает организовать задачи в более удобные для управления компоненты. Создав иерархию, можно объединить связанные задачи в более общую задачу. Общие задачи называются суммарными задачами или фазами; задачи, объединенные под суммарной задачей, называются подзадачами. Начальная и конечная дата суммарной задачи определяется начальной и конечной датами первой и последней ее подзадачи. Чтобы организовать структуру, следует использовать кнопки структуры на панели инструментов. 1. Выберите задачу, которую требуется сделать подзадачей. 2. Нажмите на панели инструментов кнопку структуры На уровень ниже, чтобы расположить задачу с отступом. 3. Работать со структурой можно разными способами. Например: уровень задачи можно быстро изменить с помощью мыши. Выберите задачу, расположите курсор на первой букве названия задачи. Когда указатель примет вид двунаправленной стрелки, перетащите ее вправо, чтобы расположить задачу с отступом, или влево, чтобы расположить ее с выступом. 4. Создайте логическую структуру задач в соответствие с разработанным планом. Создание вехи Веха - это задача, используемая для обозначения значимых событий календарного плана, например завершения основного этапа работ. При вводе нулевой длительности для задачи в Microsoft Project на диаграмме Ганта в начале соответствующего дня отображается символ вехи. Задача с нулевой длительностью автоматически помечается как веха, но вехой может быть сделана любая задача. Чтобы пометить задачу как веху, выберите задачу в поле Название задачи. Нажмите на панели инструментов кнопку Сведения о задаче, выберите вкладку Дополнительно, а затем установите флажок Пометить задачу как веху. 1. Определите вехи для каждой фазы проекта. 2. Сформируйте полный план проекта. Определение длительности задач При создании задач MS Project автоматически устанавливает длительности задач в один день. Длительности фаз не вводятся, программа рассчитывает их сама. Программа также определяет дату окончания задачи. Если длительность задачи нельзя определить точно или она требует уточнения, то после значения длительности ставится знак вопроса. 1. Уточните длительности задач в соответствие с разработанным планом проекта. Создание взаимосвязей между задачами Одним из наиболее надежных способов планирования задач является установление взаимосвязей между ними, т.е. зависимостей задач. Зависимости задач отражают обусловленность последующих задач или последователей, более ранними задачами или предшественниками. Например, если задача «Покрасить стену» должна быть выполнена до задачи «Повесить часы», можно связать две задачи, чтобы задача «Покрасить стену» стала предшественником, а задача «Повесить часы» - последователем. После того как задачи связаны, изменение дат предшественника влияет на изменение дат последователей. В Microsoft Project по умолчанию создается зависимость задач типа «Окончание-начало». Однако, поскольку зависимость «Окончание-начало» подходит не для каждого случая, для реального моделирования проекта связь задач можно изменить на «Начало-начало», «Окончание-окончание» или «Начало-окончание». 1. В меню Вид выберите команду Диаграмма Ганта. 2. Чтобы связать две или более задач друг с другом, выберите их в поле Название задачи, причем в том же порядке, в котором они должны быть связаны. Нажмите кнопку Связать задачи. 3. Устанавливать связи можно непосредственно в таблице, вводя номер предшествующей задачи в колонку Предшественники. После нажатия ОК, связь отображается на диаграмме. 4. Чтобы изменить связь задач, дважды щелкните линию связи между задачами на диаграмме, которую требуется изменить. Будет открыто диалоговое окно Зависимость задач. В поле со списком Тип выберите нужный тип связи между задачами и нажмите кнопку OK. 5. Чтобы разорвать связь между задачами, выберите эти задачи в поле Название задачи и нажмите кнопку Разорвать связи задач. Все связи удаляются, а все задачи перепланируются на основании ограничений, например «Как можно раньше» или «Фактическое окончание». 6. Связи можно редактировать в диалоговом окне Сведения о задаче, которое выводится с помощью контекстного меню, на вкладке Предшественники. 7. Связи можно редактировать с помощью Формы описания задачи. Она выводиться на экран с помощью команды Окно – Разделить. 8. Свяжите все задачи проекта в соответствие с логикой планирования. Использование задержек и ограничений. После создания и структурирования списка задач следует проверить, как задачи соотносятся друг с другом и как они соответствуют важным датам. Можно связать задачи, чтобы отразить их зависимость, например, указав, что одна задача начинается по завершении другой. Эти связи называются зависимостями задач. Вместе с длительностью и другими факторами планирования зависимости задач играют в Microsoft Project важную роль при расчете начальной и конечной даты задач. Если изменился график связанной задачи, перепланирование связанных с ней задач производится автоматически. Уточнить календарные планы задач можно с помощью конкретных ограничений дат и крайних сроков. Иногда задача может начинаться не сразу после окончания предыдущей задачи. В этом случае используют задержки или запаздывание. Запаздывание вводится как длительность, например: 1 день или как процент от длительности предшествующей задачи, например 50%. Часто для начала выполнения следующей задачи не нужно дожидаться окончания предыдущей, т.е. имеет место опережение. Опережение вводиться, так же как и запаздывание, но с отрицательным знаком. Ограничения, которые привязывают задачи к определенным датам, называются жесткими ограничениями; наиболее жесткие ограничений задают даты начала или окончания. Поскольку в Microsoft Project ограничения учитываются при расчете календарного плана, жесткие ограничения следует вводить, только если задачу необходимо начать или завершить в определенную дату. 1. Введите необходимые ограничения для задач проекта. Для задачи, завершающей проект обязательно введите ограничение Окончание не позднее и укажите запланированную дату окончания проекта. Создание повторяющихся задач Повторяющиеся задачи - это задачи, которые регулярно повторяются, например еженедельные собрания. 1. Чтобы ввести такую задачу в меню Вставка выберите команду Повторяющаяся задача. 2. В открывшемся окне определите Название задачи, длительность одного экземпляра задачи, например: 1 час. 3. Укажите ее периодичность, пределы повторения (начало – окончание). Суммарная задача проекта Суммарная задача предназначена для объединения всех проектных активностей. Чтобы отобразить суммарную задачу: 1. откройте меню Сервис, возьмите команду Параметры и на вкладке Вид установите галочку в окошке Показывать суммарную задачу. Задача вставиться как нулевая (самая первая в списке задач). 2. В окне Сведения о задаче введите название проекта. Проектный практикум Задание 4 Планирование ресурсов проекта 1. Создайте список ресурсов в соответствие с функциональными обязанностями членов команды, задайте стоимость ресурсов. 2. Распределите ресурсы на задачи, учтя выбранную структуру проекта. 3. При необходимости оптимизируйте распределение ресурсов. 4. Определите общий срок выполнения проекта. 5. Определите стоимость проекта. 6. Создайте отчет. Для этого экспортируйте план проекта в Word, при этом должны четко просматриваться названия задач и диаграмма Ганта. Укажите длительность проекта, его стоимость. Поясните, каким образом при планировании учтены стандарт и модель жизненного цикла ПО. Отчет сдайте преподавателю. Рекомендации к выполнению: Работа с Microsoft Project Создание списка ресурсов Лист ресурсов Microsoft Project используется для создания списка лиц, оборудования и материалов, составляющих рабочую группу и выполняющих задачи проекта. Список ресурсов будет содержать рабочие ресурсы или материальные ресурсы. Рабочие ресурсы - это сотрудники или оборудование; материальные ресурсы - это расходные материалы или сырье, например бетон, древесина или гвозди. 1. В меню Вид выберите представление Лист ресурсов 2. Введите список трудовых ресурсов – членов команды, участвующих в реализации проекта. 3. Определите стоимость каждого ресурса (стандартную ставку и ставку сверхурочных). Назначение ресурсов задачам Без сведений о ресурсах календарный план в Microsoft Project рассчитывается на основе длительности задачи, зависимостей и ограничений даты. Если ресурсы назначены, график работы и доступность ресурсов используются при расчете календарного плана. Если задаче назначается ресурс, создается назначение. Любой задаче можно назначить любые ресурсы, а также изменить назначения в любой момент. Задаче можно назначить несколько ресурсов, а также определить, все или не все рабочее время ресурс работает над задачей. Если назначенная ресурсу работа превышает ежедневную полную занятость, указанную в календаре рабочего времени ресурса, в Microsoft Project в представлениях ресурсов название перегруженного ресурса выделяется красным цветом. 1. Выберите команду Сервис – Выравнивание загрузки ресурсов. В открывшемся окне установите флажок Выполнять в ручную. 2. Выделите задачу, для которой нужно назначить ресурс. 3. Откройте окно Сведения о задаче и на вкладке Ресурсы введите Название и загрузку ресурсов, например: Менеджер проекта - 100%, Архитектор - 50%. 4. Введите ресурсы для всех задач в соответствие с возможностью задействовать те или иные ресурсы. После того как назначения созданы программа определяет материальные затраты и трудозатраты каждого из ресурсов для выполнения задачи и планирует распределение этих затрат на каждый день на протяжении всей длительности задачи. Результаты можно просмотреть на листе Использование ресурсов (меню Вид). В поле «Трудозатраты» отображается суммарное время, запланированное на выполнение задачи для всех назначенных ресурсов, суммарное время, запланированное для ресурса по всем назначенным задачам, или суммарное время, запланированное для ресурса по задаче. При назначении ресурса на задачу его стоимость определяется автоматически путем умножения ставки ресурса на трудозатраты и прибавлением к результату затрат на использование ресурса. Чтобы просмотреть затраты откройте представление Использование ресурсов и добавьте в таблицу столбец Затраты. Анализ стоимости проекта При анализе стоимости проекта обычно анализируется его бюджет и соотношение составляющих бюджета. В общем случае при анализе структуры затрат рассматривается распределение затрат по фазам проекта. 1. Откройте диаграмму Ганта. 2. Откройте в меню Вид таблицу Затраты, сверните все фазы. 3. Добавьте в таблицу столбец Затраты 1, в поле Текст заголовка введите Общая стоимость. 4. Откройте окно Настройка полей и переименуйте поле Затраты 1 в Общая стоимость. 5. Скопируйте во все строки этого столбца общую стоимость проекта из строки суммарной задачи. 6. Добавьте новое поле Число 1, назовите его % от общей стоимости. 7. Откройте окно Настройка полей и переименуйте поле Число 1 в % от общей стоимости. 8. Введите во все строки этого столбца формулу: Затраты/Затраты 1. Для этого в окне Настройка полей поставьте флажок Формула и откройте окно для ввода формулы (кнопка Формула), введите формулу, выбрав аргументы из списка полей. 9. В настройках поля уточните, что для расчета строк суммарных задач и групп нужно использовать туже формулу (флажок Использовать формулу). 10. После нажатия ОК в столбце % от общей стоимости отобразится распределение затрат на разработку сайта.

Проектный практикум Задание 1 Описание компании разработчика 1. Придумайте фирму, занимающуюся разработкой программного обеспечения. Определите: a. Название, количество персонала, b. Сферу деятельности, комплекс услуг, c. Миссию, d. Видение. 2. Разработайте организационную структуру фирмы: a. Создайте схему организационной структуры фирмы, b. Подробнее

Данная работа выставлена просто для ознакомления, сдавать её не рекомендую , т.к. уже была сдана раньше (в августе 2016 года), а проверяет их скорее всего один и тот же преподаватель. Однако, Вы можете заказать такую работу напрямую у меня . Мною написано и сдано уже 5 таких работ в разных вариантах. Все работы уникальны и написаны с нуля. Стоимость обговаривается индивидуально и зависит от Ваших сроков и моей загруженности.

Сама работа состоит из четырех заданий. Ниже представлен текст каждого из них.

Задание 1

Описание компании разработчика

1.Придумайте фирму, занимающуюся разработкой программного обеспечения. Определите:

1.Название, количество персонала,

2.Сферу деятельности, комплекс услуг,

4.Видение.

2.Разработайте организационную структуру фирмы:

1.Создайте схему организационной структуры фирмы,

2.Опишите бизнес - цели и задачи всех подразделений фирмы,

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

3.Разработайте методологию создания программных продуктов в фирме:

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

2.Определите фазы жизненного цикла проекта.

4.Опишите технологию создания команды проекта по разработке ПО для заказчика:

1.организационную структуру проекта

2.состав команды проекта,

3.создайте матрицу ответственности по проекту.

Отчетный документ «Описание фирмы» оформить в Word, отчет должен быть понятным и наглядным.

Задание 2

Разработка концепции проекта

1. Выберите компанию, работающую в определенной сфере бизнеса (кроме сферы IT).

2.Опишите компанию (название, численность работников, сферу деятельности, цели, управляющий аппарат).

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

4.Разработайте концепцию проекта создания ИС. Для создания концепции используйте шаблон документа с пояснениями, а также материал лекций С.Архипенкова (Архипенков С. Лекции по управлению проектами// http://arkhipenkov.ru/index.files/publications.htm.- С.42-56)

Задание 3

Разработка плана проекта

1.Создайте проект в программе Microsoft Project. При создании проекта руководствуйтесь выбранным стандартом разработки и моделью жизненного цикла ПО.

2.Разработайте календарный план проекта:

a.определите состав решаемых задач на каждой фазе проекта,

b.в каждой фазе определите конечную веху. Опишите артефакты, характеризующие каждую веху (документы, модели, схемы и т.п.).

c.определите длительности задач,

d.определите иерархическую структуру задач,

Разработка ПС обычно производится в организации, в которой одновременно могут вестись разработки ряда других программных средств. Для управления всеми этими программными проектами используется иерархическая структура управления. Традиционная структура такого рода обсуждена в работе . Она представлена на рис. 14.1.

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

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

Рис. 14.1. Структура управления разработкой программных средств.

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

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

Наиболее употребительны три подхода к организации бригад разработчиков :

обычные бригады,

неформальные демократические бригады,

бригады ведущего программиста.

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

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

В бригаде ведущего программиста за разработку порученной программной подсистемы несет полную ответственность один человек, называемый ведущим программистом (chief programmer) и являющийся лидером бригады : он сам конструирует эту подсистему, составляет и отлаживает необходимые программы, пишет документацию к подсистеме. Ведущий программист выбирается из числа опытных и одаренных программистов. Все остальные члены такой бригады, в основном, создают условия для наиболее продуктивной работы ведущего программиста. Организацию такой бригады обычно сравнивают с хирургической бригадой . Ядро бригады ведущего программиста составляют три члена бригады: помимо ведущего программиста в него входит дублер ведущего программиста и администратор базы данных разработки. Дублер ведущего программиста (backup programmer) также является квалифицированным и опытным программистом, способным выполнить любую работу ведущего программиста, но сам он эту работу не делает. Главная его обязанность – быть в курсе всего, что делает ведущий программист. Он выступает в роли оппонента ведущего программиста при обсуждении его идей и предложений, но решения по всем обсуждаемым вопросам принимает единолично ведущий программист. Администратор базы данных разработки (librarian) отвечает за сопровождение всей документации (включая версии программ), возникающей в процессе разработки программной подсистемы, и снабжает членов бригады информацией о текущем состоянии разработки. Эта работа выполняется с помощью соответствующей инструментальной компьютерной поддержки (см. лекцию 16). В зависимости от объема и характера порученной работы в бригаду могут быть включены дополнительные члены, такие как

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

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

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

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

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

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

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

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

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

Различают два вида таких стандартов:

стандарты ПС (программного продукта),

стандарты процесса создания и использования ПС.

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

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

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

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

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