Бизнес причины возникновения проекта пример

«Утверждаю»

«Утверждаю»

Председатель
управляющего
комитета,
генеральный
директор
компании «Client Company»

Генеральный
директор
«Big&Co»

__________________
Ю.
Б.
Большова

__________________
П.
Б.
Никитин

«___»
__________________ 2009 г.

«___»
__________________ 2009 г.

Согласовано:

Заместитель генерального
директора компании «Client Company»

Канаева
Елена Владимировна

______________________

Руководитель проекта
со стороны компании «Client Company»,
начальник
отдела БП департамента
информатизации

Бахвалова
Евгения Анатольевна

______________________

Руководитель проекта
со стороны «Big&Co»

Захарова
Екатерина Павловна

______________________

Управление
документом

Авторы

Генеральный
директор компании «Client Company» Большова
Ю.Б.

Файл

B2kaSyZlnm.R1fK

Создан

14.09.2009 18:32

Последнее
редактирование

17.09.2009 18:30

Количество
страниц

8

Версия

Дата
изменения

Описание
изменения

Автор
изменения

Подпись

01

14.09.2009

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

Большова
Ю.Б.

02

17.09.2009

Уточнены
сроки проекта

Большова
Ю.Б.

Согласование

  • Замечания

№

Дата
поступления

Наименование
документа

Автор
замечания

Подпись

1.

2.

3.

  • Обработка
    замечаний

№

Дата
обработки

Версия
документа, учитывающая замечание

Исполнитель

Подпись

1.

Бизнес-причины возникновения проекта

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

Потребность
во внедрении ERP-системы связана со
следующими причинами:

  1. отсутствие
    интегрированной системы, которая
    предоставляет данные для принятия
    решения всем уровням управления;

  2. большие
    операционные и временные издержи ввиду
    отсутствия общего электронного
    документооборота и создания отчетности;

  3. существующая
    система обмена информацией не
    соответствует структуре предприятия;

  4. наличие
    недостатков в основных бизнес-процессах
    предприятия.

Цели проекта

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

Цели проекта:
создание и внедрение ERP-системы с целью
автоматизации основных бизнес-процессов
«Client Company». Срок – до 01.10.2011. Качество –
согласно спецификации (требования
Заказчика, закрепленные в техническом
задании).

Требования к проекту

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

  • Поддержка совместного
    использования информации различными
    подразделениями «Client Company» и
    иерархически-ролевого доступа к ней.

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

  • Повышение эффективности
    использования основных активов и
    ресурсов компании.

  • Сокращение
    административно-управленческих
    косвенных затрат, в том числе на закрытие
    финансовой отчетности за период (месяц,
    квартал, год) и на ведение параллельного
    учета по МСФО.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
Источник

УДК 004

РАЗРАБОТКА ИНИЦИАЦИИ И УСТАВА ПРОЕКТА ДЛЯ СОЗДАНИЯ МОБИЛЬНОГО ПРИЛОЖЕНИЯ

Давыдова А.А.1, Бабенко А.В.2, Новикова Т.Б.3
1Магнитогорский государственный технический университет им. Г.И. Носова, студент группы АПИп-14 ИЭиАС
2Магнитогорский государственный технический университет им. Г.И. Носова, студент группы АПИп-14 ИЭиАС
3Магнитогорский государственный технический университет им. Г.И. Носова, кандидат педагогических наук, доцент кафедры прикладной информатики

Аннотация
В статье рассматриваются разработанный устав и инициация проекта по разработке мобильного приложения. Начальным этапом любого проекта является его стартап, который оформляется в соответствии с PM Book. Устав проекта является документом, который подписывается разработчиком и заказчиком проекта и в дальнейшем реализуется с использованием MS Project.

Ключевые слова: ГОСТ, мобильное приложение, Проект

DEVELOPMENT AND INITIATION OF THE CHARTER OF THE PROJECT FOR MOBILE APPLICATIONS

Davydova A.A.1, Babenko A.V.2, Novikova T.B.3
1Nosov Magnitogorsk State Technical University, student
2Nosov Magnitogorsk State Technical University, student
3Nosov Magnitogorsk State Technical University, Ph.D., Associate Professor, Department of Applied Informatics

Abstract
In the article the developed statutes and initiate a project to develop mobile applications. The initial stage of any project is its start, which is made in accordance with the PM Book. Project Charter is a document that is signed by the developer and the client project in the future is implemented using MS Project.

Библиографическая ссылка на статью:
Давыдова А.А., Бабенко А.В., Новикова Т.Б. Разработка инициации и устава проекта для создания мобильного приложения // Современная техника и технологии. 2016. № 11. Ч. 2 [Электронный ресурс]. URL: https://technology.snauka.ru/2016/11/11412 (дата обращения: 24.02.2023).

1. 1.1.  Бизнес-потребность

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

1.2  Описание содержания продукта

Мобильное приложение будет содержать в себе большую базу данных учебных материалов с множеством курсов с удобной классификацией, разбором типовых заданий, упражнений для самостоятельного выполнения и возможностью самим выбирать необходимые курсов. Приложение сможет проверять решения самостоятельных заданий, отмечать ошибки и в случае необходимости выводить подсказки [1, 2, 3].

1.3  Стратегический план

Миссия компании: Создать наилучшие условия для самостоятельного обучения

Цели:

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

2.      Бизнес-кейс проекта

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

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

3.      Имеющиеся соглашения

Договор между участниками и ресурсами проекта

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

Ситуация на рынке:

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

Имеющиеся человеческие ресурсы:

Навыки: Владение одним или несколькими языками программирования из перечня: HTML5, Java, C++, Objective C, Swift и C#

Целевая аудитория пользователей: школьники и студенты

Государственные стандарты:

  1. ГОСТ 19.101-77
  2. ГОСТ 19.102-77
  3. ГОСТ 19.201-78
  4. ГОСТ Р ИСО/МЭК 9126-93
  5. ГОСТ Р ИСО 9241-210-2012
  6. ГОСТ Р ИСО/МЭК 12119-2000 «
  7. ГОСТ 34.602-89

5.      Активы процессов организации, которые могут оказывать влияние на процесс разработки устава проекта

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

Бизнес-причины возникновения проекта

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

Потребность создания приложения связана со следующими причинами:

  1. Необходимость приложения, которое содержало бы в себе большую базу данных учебных материалов по множеству курсов с удобной классификацией, приятным интерфейсом и возможностью выбирать необходимые курсы
  2. Отсутствие универсального приложения с большим выбором курсов, которое содержало бы не только теоретический материал, но и взаимодействовала с пользователем, давало ему задачи для самостоятельного решения, проверяло ход решения, в случае необходимости давало подсказки, и предоставляла контрольные работы и тесты по пройденному материалу [4, 5, 6]

Бизнес-цель: получить универсальное обучающее приложение

Цели проекта: создание и раскрутка мобильного приложения  с целью получения прибыли. Срок – до 10.03.2017. Качество – согласно спецификации (требования Заказчика, закрепленные в техническом задании)

Ожидаемые результаты проекта

Рабочее мобильное приложение с числом скачиваний более 1000

Заинтересованные стороны

— Пользователи мобильных устройств на платформах Android и IOS

— Инициатор проекта

— Руководитель проекта

— Члены команды разработки

 Требования к проекту

  1. Создание обучающего мобильного приложения на платформах Android и IOS
  2. Продвижение данного приложения в PlayMarket и AppStore
  3. Своевременный выпуск обновлений

Факторы внутренней среды

  • Политика руководства компании «Планета знаний»
  • Политика персонала компании «Планета знаний» к проекту
  • Корпоративная культура компании «Планета знаний»
  • Команда проекта

Допущения

Критически важный персонал не покинет компанию

Любые предложения и изменения будут обсуждаться с руководителем проекта

Сроки выполнения проекта могут быть пересмотрены в ходе реализации проекта в сторону уменьшения или увеличения [7, 8, 9]

Ограничения

Государственные стандарты

Технологии

Языки программирования HTML5, Java, C++, Objective C, Swift и C#

 Полномочия команды управления проектом

Роль ФИО Контактная информация Должностная ответственность
Инициатор (спонсор) проекта со стороны компании «Планета знаний» Климов Александр Викторович Магнитогорск, ул. Вокзальная 5

Телефон:89373679726

 — Генеральная ответственность за материальную ответственность

— Контроль за процессом разработки

— Утверждение или отклонение предлагаемых изменений и дополнений в продукт
Руководитель проекта со стороны компании «Планета знаний» Ульянов Сергей Александрович Магнитогорск, проспект Ленина 54

Телефон: 89064533627

 — Подготовка общего плана проекта и детальных планов работ

— Решение проблем, возникающих на стадиях и фазах проекта

— Предоставление отчётов о состоянии работ на проекте

— Обеспечение сохранности проектной документации

 Целью проекта является создание мобильного приложения «Всезнайка» на платформах Android и IOS

Цели проекта и критерии их достижения

Цель Критерий Значение
1. Анализ бизнес-процессов Эффективность управления бизнес-процессами, качество конечного результата Выявлены и устранены недостатки бизнес-процессов
2. Разработка мобильного приложения на платформах Android и IOS Обеспечение свободного доступа к приложению Определена готовность к разработке

Требования к проектному решению

Продукт должен удовлетворять следующим требованиям и содержать в себе:

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

Границы проекта

Методологии реализации проекта

Проект разработки приложения состоит из следующих стадий:

1. Предпроектное обследование

2. Разработка ТЗ

3. Проектирование UI/UX

4. Создание концепции дизайна

5. Разработка

6. Тестирование

7. Отладка

8. Второе тестирование

9. Создание иконки приложения
10. Запуск приложения в Play Market и AppStore

Библиографический список

  1. Chusavitina G.N., Zerkina N.N. CYBER EXTREMISM PREVENTIVE MEASURES IN TRAINING OF FUTURE TEACHERS : В сборнике: SGEM 2015 INTERNATIONAL MULTIDISCIPLINARY SCIENTIFIC CONFERENCE ON SOCIAL SCIENCES AND ARTS 2-nd INTERNATIONAL MULTIDISCIPLINARY SCIENTIFIC CONFERENCE ON SOCIAL SCIENCES AND ARTS. 2015. С. 275-280.
  2. Большакова О.Н., Чусавитина Г.Н. Применение методики PМI для управления рисками проекта по продвижению интернет-магазина : В сборнике: КЛАСТЕРНЫЕ ИНИЦИАТИВЫ В ФОРМИРОВАНИИ ПРОГРЕССИВНОЙ СТРУКТУРЫ НАЦИОНАЛЬНОЙ ЭКОНОМИКИ сборник научных трудов Международной научно-практической конференции, в 2-х томах. Ответственный редактор Горохов А.А.. 2015. С. 64-68.
  3. Чусавитина Г.Н. Имитационное моделирование управления рисками информационной безопасности ИКТ-насыщенной образовательной среды вуза : В сборнике: Инновационные технологии обучения в высшей школе материалы Всероссийской научно-практической конференции. 2009. С. 23-28.
  4. Чусавитина Г.Н. Проблемы организации учебно-воспитательной работы со школьниками в целях нейтрализации негативного воздействия ИКТ // Вестник Московского государственного областного университета. Серия: Открытое образование. 2006. Т. 1. № 2. С. 100-105.
  5. Чусавитина Г.Н. Развитие компетенций научно-педагогических кадров по обеспечению информационной безопасности в ИКТ-насыщенной среде : В сборнике: Спрос и предложение на рынке труда и рынке образовательных услуг в регионах России2011. С. 338-345.
  6. Чусавитина Г.Н., Макашова В.Н., Колобова О.Л. УПРАВЛЕНИЕ ИТ-ПРОЕКТАМИ : учебно-методическое пособие по дипломному и курсовому проектированию. –  Магнитогорск, 2015.
  7. Чусавитина Г.Н., Чусавитин М.О., Сахнова Т.Н. Разработка модели управление рисками, порождаемыми применением дистанционных образовательных технологий в вузе : В сборнике: Совершенствование подготовки IT-специалистов по направлению “Прикладная информатика” для инновационной экономики сборник научных трудов. Москва, 2008. С. 216-218.
  8. Швалев И.С., Чусавитина Г.Н., Давлеткиреева Л.З. Сравнительная характеристика автоматизированных инструментальных средств управления информационными рисками // Современные научные исследования и инновации. 2012. № 11 (19). С. 5.
  9. Чусавитина Г.Н., Чернова Е.В. Толерантность как средство борьбы с экстремизмом и терроризмом : В книге: Современные проблемы науки и образования Материалы XLIX внутривузовской научной конференции. Магнитогорский государственный университет; Редакторы: З.М. Уметбаев, П.Ю. Романов, Т.В. Саляева. 2011. С. 100-102.

Все статьи автора «Давыдова Анастасия Алексеевна»

Источник

Процедура адаптации модели ЖЦ ИС

При адаптации модели ЖЦ ИТ в интересах организации или проекта в соответствии с применяемыми политикой и процедурами должны выполняться следующие действия.

  1. Руководителем проекта (РП) определяются и документируются обстоятельства, воздействующие на адаптацию. Эти воздействия включают (но не ограничиваются) перечисленное ниже:
    • стабильность и разнообразие среды функционирования;
    • коммерческие или эксплуатационные риски, касающиеся заинтересованных сторон;
    • новизну, размеры и сложность;
    • дату начала и продолжительность применения;
    • вопросы целостности, такие как безопасность, защищенность, секретность, удобство применения,
    • доступность;
    • вновь возникающие технологические возможности;
    • бюджетный профиль и доступные организационные ресурсы;
    • готовность предоставления услуг обеспечивающими системами.
  2. При наличии свойств, критичных по отношению к системе, руководитель проекта должен учесть структуры ЖЦ, которые рекомендованы или установлены в качестве обязательных стандартами, соответствующими области критичности.
  3. Далее руководитель проекта собирает входные данные от следующих заинтересованных сторон проекта:
    • правообладатели системы;
    • заинтересованные стороны соглашения, заключенного организацией;
    • стороны, вносящие вклад в организационные функции.
  4. Руководитель проекта определяет новую (модифицированную) модель жизненного цикла системы в терминах стадий, их назначения, целей и результатов, которые достигаются вследствие применения процессов жизненного цикла в пределах каждой стадии.
  5. Проектный офис принимает решение об адаптации базовой модели.
  6. Модификация ЖЦ ИС приобретает локальный (для одного проекта и для одной (под)системы) или общекорпоративный характер по решению проектного офиса, по результатам апробации предложенной РП модификации.

Таблица
1.3.
Шаблон адаптации модели жизненного цикла информационной системы

Описание причины:
Действия Базовый Модифицированный Характеристики модифицированного этапа/процесса
Этап Процесс Этап Процесс Назначение Цель Результат
_
_
Дата подачи заявки (руководитель проекта):
Дата принятия решения (проектный офис):
Дата начала применения:

Разработка технико-экономического обоснования

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

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

Согласно последним исследованиям 75% компаний ставит именно такие цели при подготовке ТЭО, в то же время всего лишь 40% из них считают, что используемые ими методы позволяют получить корректную оценку эффективности внедряемого ИТ-решения [7].

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

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

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

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

Таблица
1.4.
Матрица структурирования выгод ИТ-проекта (адаптировано из [7])

ХАРАКТЕР ВОЗДЕЙСТВИЯ НА БИЗНЕС
Создание новых возможностей Повышение эффективности операций Отказ от операций
СТЕПЕНЬ ОПРЕДЕЛЕННОСТИ Финансовые
Количественные
Измеримые
Качественные

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

  1. Качественные: выгоды, которые могут быть зафиксированы на уровне экспертного мнения или суждения. В то время как данный тип выгод вполне допустим, необходимо всегда предупреждать ситуацию, когда без четкого значения выгоды на этапе планирования очень сложно определить степень ее реализации на момент принятия результатов проекта. В связи с этим рекомендуется разрабатывать четкие критерии реализации качественных выгод в самом начале проекта и, по возможности, собирать дополнительную информацию для «переноса» качественных выгод в более объективные категории.
  2. Измеримые:выгоды данного типа поддаются измерению. В распоряжении аналитика есть инструменты и техники, например, ключевые показатели эффективности, позволяющие измерить их значение до внедрения. Для данного типа бизнес-выгод характерна невозможность оценить значение соответствующего показателя после внедрения.
  3. Количественные:аналогично измеримым, количественные выгоды характеризуются наличием показателей, позволяющих измерить их значение до выполнения проекта. Но, в отличие от измеримых, значение показателей количественных бизнес-выгод на момент окончания проекта можно оценить с высокой степенью точности.
  4. Финансовые:это тип бизнес-выгод, которые могут быть выражены в терминах финансовых показателей. Отнесение бизнес-выгоды к данной категории должно производиться только в том случае, если в распоряжении аналитика имеется достаточно достоверная информация о финансовой оценке соответствующих показателей. Очевидно, финансовые выгоды есть результат «обогащения» количественных бизнес-выгод финансовыми данными. Агрегированные финансовые выгоды проекта образуют базу для построения финансовой модели проекта (ROI-модель) и расчета инвестиционных показателей: NPV, IRR, периода окупаемости.

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

Формирование бизнес-цели проекта

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

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

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

Разработка устава проекта

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

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

  • стратегические и тактические цели организации-заказчика;
  • формулировка требований организации-заказчика;
  • ТЭО ;
  • контракт;
  • внутрикорпоративная методология управления проектами и соответствующие политики.

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

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

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

№ Раздел Пояснения
1. Название проекта Каждый проект должен иметь название, отражающее его суть и в то же время достаточно яркое для привлечения внимания
2. Бизнес-причина возникновения проекта Производственная необходимость, или самое общее описание проекта и требований к продукту, производство которого является результатом выполнения проекта. Формулировка причины фактически дает ответ на вопрос, зачем выполняется данный проект. Причины возникновения проекта могут основываться на требованиях рынка, техническом прогрессе, юридических требованиях или государственном стандарте
3. Бизнес-цель Сформулирована заказчиком, исходя из стратегических и тактических целей компании, см. раздел «Формирование бизнес-цели проекта «
4. Требования, удовлетворяющие потребности, пожелания и ожидания заказчика, спонсора и других участников проекта Видение организацией-заказчиком, как правило, высокоуровневое, способов достижения поставленной бизнес-цели или решения существующей проблемы. Проект считается успешным, если ожидания заказчика и участников проекта оказались выполненными, следовательно, к моменту формирования устава проекта его участники должны быть идентифицированы. Все задокументированные в уставе требования должны быть учтены при выполнении стоимостной оценки проекта
5. Расписание основных контрольных событий На этапе формирования устава должно быть обязательно указано время начала и завершения проекта; при необходимости отмечаются ключевые вехи проекта, принципиальные для организации-заказчика.
Вообще рекомендуется ограничить количество контрольных событий теми, которые абсолютно необходимы, т.е. обычно тремя-пятью. Иными словами, принимая во внимание цель устава и соответствующий уровень детализации, совершенно излишне разрабатывать длинный список событий — это только создаст дополнительные ограничения для выбора методологии реализации проекта. Кроме того, организации, придающие значение себестоимости, имеют тенденцию указывать для основных событий специфику бюджета ресурсов или бюджета средств [18]
6. Участники проекта Перечисление заинтересованных сторон проекта, иными словами, круга лиц и организаций, на которых оказывает воздействие реализация данного проекта и которые сами могут воздействовать на него. Подробнее об участниках проекта см. раздел «Идентификация участников проекта»
7. Окружение проекта Перечисление всех организационных факторов, характеризующих обстановку вокруг проекта и на рынке. Также необходимо указать благоприятные и неблагоприятные особенности среды, в которой проект будет выполняться (внутри и вне компании), и способность организации-исполнителя к его осуществлению, а организации-заказчика — к использованию его результатов.
Далее (см. рис. 1.2) будет показан один из эффективных способов выполнения комплексного анализа окружения и участников проекта. При использовании этого подхода сначала определяется достаточно большое число факторов, действующих в окружении проекта; они заносятся в соответствующий сектор. Затем выделяются наиболее критичные из них (прямоугольники — участники, овалы — факторы окружения) [20]
8. Допущения относительно организации и окружения, а также внешние допущения Набор условий, которые должны быть выполнены наряду с созданием продукта проекта, для достижения результата проекта. Допущения обуславливают риски проекта; во время проекта происходит их мониторинг. Пример допущений:

  • o компетенции команды проекта достаточно для выполнения предпроектного обследования;
  • o организацией-заказчиком будет выделен персонал для выполнения работ по поддержке проекта.

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

  • увеличение стоимости проекта не более чем на 10%;
  • не менее 40% членов команды проекта, предоставляемых исполнителем, заняты на 100% в проекте.

Обратите внимание, что при составлении устава проекта ограничения формулируются со стороны организации-заказчика об организации-исполнителе и о проекте в целом
10. Объем денежных средств, выделенных на достижение бизнес-цели На данном этапе указывается сумма средств, которую организация-заказчик готова выделить на достижение сформулированной бизнес-цели проекта. Указанная сумма является результатом определения порядка величины и ошибка в оценке может составлять от ~ -20% до +100% [18]
11. Назначение руководителей проекта и общее определение полномочий ключевых членов проектной команды: РП, спонсор, координатор Руководитель проекта назначается уставом проекта и формально приступает к выполнению своих обязанностей на следующий день после подписания устава проекта. Руководитель, или менеджер, проекта несет основную ответственность за общее планирование, направление и контроль проекта в течение всех фаз его жизненного цикла, ставя целью получение желаемого результата в рамках утвержденного бюджета и расписания. Основная задача руководителя проекта — объединение усилий всех лиц, участвующих в проекте. Для решения этой задачи менеджер проекта наделяется полномочиями по проекту, т.е. правом отдавать функциональным лидерам проекта распоряжения, необходимые для планирования, исполнения, мониторинга, оценивания и контроля работ, которые должны быть выполнены по данному проекту. Руководство проектом также включает в себя получение информации, необходимой для планирования, мониторинга, оценивания и контроля проекта [8,18].
Роль спонсора проекта обычно берет на себя (не назначается!!!) менеджер высшего звена, который действует от лица руководства компании, финансирующей или исполняющей проект2Авторы рекомендуют включать в проект руководителей и двух спонсоров проекта — по одному от заказчика и исполнителя.
.

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

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

Роль спонсора проекта обычно не предполагает работы с полной занятостью вне зависимости от размера проекта [8,18]. Администратор (координатор) проекта — это специфическая функция на проекте, которая необходима для поддержки работ, связанных с администрированием и документированием функционирования проектной организации и обеспечением инфраструктуры проекта. Работа администратора имеет своей ключевой задачей поддержку руководителя проекта на операционном уровне с целью его высвобождения для интеллектуально-сложных задач. В обязанности координатора проекта может входить: администрирование проектных контрактов и договоров на протяжении всего ЖЦ, организация периодического сбора статуса выполнения проекта и т.п. Формировать всю команду и тем более сразу указывать имена
всех ее членов не принято — функциональные руководители обычно выделяют для проекта своих подчиненных, только когда руководитель проекта составит план потребности в ресурсах, после определения состава работ проекта, и отправит официальный запрос на ресурсы, утвержденный спонсором проекта [18]
Источник


1 чел. помогло.

скачать
^

Бизнес-причины возникновения проекта


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

Потребность во внедрении ERP-системы связана со следующими причинами:

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

^
Бизнес-цель: Получить инструмент для эффективного принятия управленческих решений.

Цели проекта: создание и внедрение ERP-системы с целью автоматизации основных бизнес-процессов «Client Company». Срок – до 01.10.2011. Качество – согласно спецификации (требования Заказчика, закрепленные в техническом задании).

^

  • Создание интегрированного ИТ-решения на базе гибкой, тиражируемой и быстро реагирующей на изменения платформы с единым пользовательским интерфейсом.
  • Поддержка совместного использования информации различными подразделениями «Client Company» и иерархически-ролевого доступа к ней.
  • Повышение прозрачности функционирования и управляемости компании за счет обеспечения информации в необходимом аналитическом разрезе для принятия оперативных управленческих решений руководством компании.
  • Повышение эффективности использования основных активов и ресурсов компании.
  • Сокращение административно-управленческих косвенных затрат, в том числе на закрытие финансовой отчетности за период (месяц, квартал, год) и на ведение параллельного учета по МСФО.

^
Дата начала выполнения проекта: 01.08.2010

Дата завершения проекта: 01.10.2011.

Участники проекта

Компания «Client Company» осуществляет данный проект совместно с компанией «Big&Co», выступающей генеральным подрядчиком по проекту.

Инициатор проекта (спонсор) – генеральный директор компании «Client Company» Большова Ю.Б.

Заказчик – компания «Client Company».

Руководители проекта, команда проекта – определены в п. .

Функциональные группы – будут определены в содержании проекта.

Генеральный подрядчик – «Big&Co».

Лицензоры – Microsoft.

Органы власти – Фонд социального страхования РФ, Пенсионный фонд РФ, Фонд обязательного медицинского страхования, налоговая инспекция, Правительство РФ.
^

  • Факторы внешней среды
    • клиенты
    • партнеры
    • конкуренты
    • законодательство
    • экономические условия, такие как финансовые показатели и др.
  • Факторы внутренней среды
    • политика руководства компании «Client Company»
    • отношение персонала компании «Client Company» к проекту
    • корпоративная культура «Client Company»
    • команда проекта

^
Допущения

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

Ограничения

Окружение проекта

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

  • организационной структурой компании;
  • корпоративной культурой;
  • государственными стандартами и законодательством;
  • существующими в компании процедурами управления персоналом;
  • существующими человеческими ресурсами (навыки, знания, специализации).

Технологии

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

    — Microsoft Dynamics AX;

    — Microsoft SQL Server – СУБД, используемая для работы Microsoft Dynamics AX;

    — Локальные ИС – локальные информационные системы Заказчика;

    — Приложения Microsoft Office;

    — Microsoft Visio, ARIS – графические системы для отражения бизнес-процессов («Как есть» и «Как будет»).

^

Стоимость проекта


Совокупная стоимость проекта внедрения ERP-системы для компании «Client Company» составит 2 000 000 евро (без НДС). Данный показатель состоит из стоимости прав пользования ERP-системы (лицензионная составляющая), стоимости консалтинговых услуг и стоимости обучения конечных пользователей.
^

Руководитель проекта


Инициатором (спонсором) проекта является генеральный директор компании «Client Company» Большова Ю.Б..

Руководителем проекта со стороны компании «Client Company» назначается ведущий специалист департамента информатизации компании «Client Company» Бахвалова Евгения Анатольевна.

Руководителем проекта со стороны «Big&Co» назначается Захарова Екатерина Павловна.

^

Роль ФИО Контактная информация ^
Спонсор проекта со стороны компании «Client Company» Большова Юлия Борисовна 119017, г. Москва, ул. Большая Ордынка, д.24/26 (офисный адрес), тел. 8(495)7889085 (доб.1234)
  • генеральная ответственность за финансовое обеспечение проекта
  • обеспечение контроля внедрения результатов проекта в те бизнес-процессы/отделы, которые входят в сферу влияния проекта
  • принятие окончательного решения при возникновении спорной ситуации
  • утверждение изменений основных параметров проекта, обеспечение при необходимости дополнительного финансирования
  • участие в управлении проектом и своевременное принятие решений, обеспечивающих успешное завершение проекта
  • утверждение подходов к выполнению проекта и прием результатов проекта в соответствии с утвержденными подходами
  • утверждение документов, завершающих этапы работ по проекту, и акта сдачи-приемки работ по договору
Спонсор проекта со стороны «Big&Co» Никитин Павел Борисович Малая Ордынка, д.27 (офисный адрес), тел. 8(495)7950807 (доб.8123)
  • генеральная ответственность за достижение результатов проекта
  • утверждение изменений основных параметров проекта, обеспечение при необходимости дополнительными людскими ресурсами
  • участие в управлении проектом и своевременное принятие решений, обеспечивающих успешное завершение проекта
  • утверждение подходов к выполнению проекта и прием результатов проекта в соответствии с утвержденными подходами
  • утверждение документов, завершающих этапы работ по проекту, и акта сдачи-приемки работ по договору
Руководитель проекта со стороны компании «Client Company» Бахвалова Евгения Анатольевна 119017, г. Москва, ул. Большая Ордынка, д.24/26 (офисный адрес), тел. 8(495)7889085 (доб.1235)
  • обеспечение сохранности проектной документации на электронных и бумажных носителях
  • участие в подготовке общего плана на этапы проекта и детальных планов работ проектных групп на месяц
  • формирование структуры управления
  • разработка проектных процедур
  • оперативное руководство выполнением планов работ проекта
  • проведение оперативных рабочих совещаний
  • выполнение функций председателя на заседаниях оперативного совета
  • организация (подготовка повестки заседаний) заседаний управляющего комитета и оперативного совета
  • решение проблем, возникающих на уровне подразделений проектной группы, и, при необходимости, их вынесение на уровень управляющего комитета
  • представление на оперативном совете еженедельного (ежемесячного) отчета о статусе проекта, управляющему комитету – отчетов о состоянии работ на проекте, контроль своевременности рассылки протоколов заседаний
Руководитель проекта со стороны «Big&Co» Захарова Екатерина Павловна 119018, г. Москва, ул. Малая Ордынка, д.27 (офисный адрес), тел. 8(495)7950807 (доб.8976)
  • выполнение работ на проекте в полном соответствии с установленными объемом и сроками, контроль качества
  • подготовка общего плана на фазу проекта и детальных планов работ проектных групп на месяц
  • подготовка повестки заседаний оперативных советов и участие в заседаниях оперативного совета
  • решение проблем, возникающих на уровне проектных групп, группы интеграции, и, при необходимости, их вынесение на уровень оперативного совета
  • согласование проектных решений
Команда исполнителей проекта – предмет дальнейшего уточнения при планировании проекта.

Содержание проекта утверждает управляющий комитет

В сферу общей ответственности руководителей проекта входит:

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

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

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

^

страница 45/62
Дата 23.01.2012
Размер 6,91 Mb.
Тип Учебник, Образовательные материалы
Источник

С этим файлом связано 1 файл(ов). Среди них: Практическая работа №8 операц. сист.doc.
Показать все связанные файлы

Подборка по базе: Практическая работа №1.docx, практическая работа 2гот.docx, Практ. работа по Бизносу-коммуникации.docx, Практическая работа.rtf, практическая работа 310120223.doc, Курсовая работа по химии на тему_ _Жизнь и деятельность Марии Кю, Практическая работа по теме «Целостный педагогический процесс ед, Исследовательская работа _Выращивание салата в комнатных условия, сам работа 1.docx, Практическая работа. Дорожная карта.docx

Практическая работа №1

Формирование бизнес-цели проекта. Разработка устава проекта.
Цель работы: Изучение основных понятий: бизнес-цель, устав проекта, технико-экономическое обоснование проекта. Формирование практических умений и навыков формулирования цели организации; разработки устава проекта, технического задания ИС.

В результате выполнения практической работы студент должен:

знать:

  • решения задач обработки информации;
  • основные процессы управления проектом разработки.

уметь:

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

Задание для практической работы:

  1. Изучить теоретическую часть
  2. Выполнить практическую часть
  3. Ответить на контрольные вопросы
  4. Оформить отчет.

Теоретическая часть
Бизнес-цель — это описание фактора, побуждающего к выполнению проекта. Ее формирование производится на стратегическом уровне, то есть бизнес-цель выступает в качестве связующего звена между глобальными задачами, стоящими перед организациями, и планируемым к реализации проектом. При отходе от стратегического видения происходит смещение бизнес-цели в сторону тактических и даже операционных задач, на уровне которых целью проекта видится «просто выдать продукт», а не достичь какой-либо тактической цели, поддерживающей стратегические цели организации. Этого нельзя допускать: бизнес-цель проекта должна всегда носить тактический или стратегический характер, но в то же время быть предельно точной и ясной (очень редко удается применить широко известный метод SMART к построению бизнес-цели проекта.

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

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

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

  • функцию постановки задачи;
  • функцию согласования;
  • авторизационную функцию;
  • функцию повышения дисциплины;
  • консолидационную функцию;
  • интеграционную функцию.

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

  1. Обоснование выполнения уникальной задачи развития.
  2. Цели, задачи и результаты.
  3. Имя и фамилию PM, границы его ответственности и полномочия.
  4. Определение и структуру продукта.
  5. Интересы и ожидания участников.
  6. Критерии успеха.
  7. Принципы организации и управления проектом.

Практическая часть
Рассмотрев пример, на основе своей предметной области (смотри номер варианта) разработать устав для выбранного направления деятельности и техническое задание для ИС.
ВАРИАНТЫ ЗАДАНИЙ

  1. Прокат автомобилей
  2. Библиотечный фонд города
  3. Спортивный клуб
  4. Управление складом
  5. Автошкола
  6. Химчистка
  7. Автомастерская
  8. Компания по продаже мед.техники
  9. Страховая компания
  10. Гостиница
  11. Ломбард
  12. Оптовая база
  13. Завод по производству металлоизделий
  14. Ювелирная мастерская
  15. Предприятие по организации свадебных торжеств
  16. Бюро по трудоустройству
  17. Нотариальная контора
  18. Производство мебели
  19. Производство детских игрушек
  20. Поликлиника
  21. Магазин розничной торговли
  22. Спортивный клуб
  23. Аэропорт
  24. Магазин по ремонту и продаже компьютеров и комплектующих
  25. Строительная организация
  26. Игровая комната
  27. Строительная организация
  28. Фотоцентр
  29. Городской зоопарк

Техническое задание ИС
ПРИМЕР:

В качестве предметной области выбрана тема «Отдел кадров. Учет персонала».

1. Этап разработки раздела «Общие сведения»:

  • Полное наименование ИС: «Отдел кадров. Учет персонала».
  • Шифр темы: 00001.
  • Предприятие-разработчик системы: Лаборатория баз данных “БД”, ул. 50 лет Октября, 86, тел. 32-12-02.
  • Предприятие-заказчик системы: ООО «ЛюксАвто».
  • Система создается на основании технического задания (ТЗ). ТЗ на АС является основным документом, определяющим требования и порядок создания автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие. Кроме того, при создании системы используются ГОСТ 34.602-89 “Техническое задание на создание автоматизированной системы”.
  • Плановый срок начала работ: 01.04.2010.
  • Плановый срок окончания работ: 31.05.2010.
  • Автоматизируемая система создается на коммерческой основе.
  • Порядок оформления и предъявления заказчику результатов работы по созданию системы определяется после получения начальной версии продукта, в которой должны быть реализованы все основные функции, определенные в ТЗ и утвержденные заказчиком.

2. Этап разработки раздела «Назначение и цели создания системы»:

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

3. Этап разработки раздела «Характеристики объекта автоматизации»

Краткие сведения о предприятии.

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

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

Организационная структура.

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

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

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

Схема информационных потоков процесса показана на рисунке 2.

Рис.2 Схема информационных потоков процесса “Учет персонала”
В целом, до начала разработки данной системы вся отчетность велась путем составления личных карточек на бумажных носителях, из которых при необходимости выбирались те или иные сведения. Таким образом, видно, насколько рационально использовать базу данных и приложение по работе с ней. Во-первых, сокращается объем бумажного документооборота и время на роботу с информацией о сотрудниках, данные о любом сотруднике можно получить путем запросов, кроме того, заметно сократится время на формирование отчетов для руководства и бухгалтерии.

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

  • Сотрудники.
  • Адрес.
  • Образование.
  • Подразделение.
  • Приказ о зачислении.
  • Штатное расписание.
  • Должность.
  • Карточка учета.

4. Этап разработки раздела «Требования к ИС»

Требования к системе в целом

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

Ввод в действие ИС должен приводить к полезным технико-экономическим, социальным результатам:

  • уменьшению времени по учету данных о сотрудниках;
  • уменьшение времени на формирование отчетов, приказов и справок.

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

Требования безопасности устанавливаются в инструкциях по эксплуатации технических средств.

Требования к функциям (задачам), выполняемым системой

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

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

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

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

Требования к информационному обеспечению ИС

Информационное обеспечение ИС должно включать:

  • данные о сотрудниках;
  • приказы о зачислении;
  • штатное расписание;
  • личные карточки.

Требования к программному обеспечению ИС

Для функционирования базы данных подходят операционные системы Windows , Vista. Диалоговый режим требует объектно-ориентированную систему программирования — Borland Delphi , а СУБД – Access.

Требования к техническому обеспечению АС

Минимальные требования к техническому обеспечению АС следующие:

  • Pentium IV;
  • ОЗУ 512 Мбайт;
  • 10 Мбайт дисковой памяти;
  • принтер формата А4.

5. Этап разработки раздела «Стадии и этапы разработки»

Стадии разработки

Разработка должна быть проведена в три стадии:

  • разработка технического задания;
  • рабочее проектирование;
  • внедрение.

6. Этапы разработки

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

На стадии рабочего проектирования должны быть выполнены перечисленные ниже этапы работ:

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

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

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

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

№ Раздел Пояснения
1. Название проекта Каждый проект должен иметь название, отражающее его суть и в то же время достаточно яркое для привлечения внимания
2. Бизнес-причина возникновения проекта Производственная необходимость, или самое общее описание проекта и требований к продукту, производство которого является результатом выполнения проекта. Формулировка причины фактически дает ответ на вопрос, зачем выполняется данный проект. Причины возникновения проекта могут основываться на требованиях рынка, техническом прогрессе, юридических требованиях или государственном стандарте
3. Бизнес-цель Сформулирована заказчиком, исходя из стратегических и тактических целей компании.
4. Требования, удовлетворяющие потребности, пожелания и ожидания заказчика, спонсора и других участников проекта Видение организацией-заказчиком, как правило, высокоуровневое, способов достижения поставленной бизнес-цели или решения существующей проблемы. Проект считается успешным, если ожидания заказчика и участников проекта оказались выполненными, следовательно, к моменту формирования устава проекта его участники должны быть идентифицированы. Все задокументированные в уставе требования должны быть учтены при выполнении стоимостной оценки проекта
5. Расписание основных контрольных событий На этапе формирования устава должно быть обязательно указано время начала и завершения проекта; при необходимости отмечаются ключевые вехи проекта, принципиальные для организации-заказчика. Вообще рекомендуется ограничить количество контрольных событий теми, которые абсолютно необходимы, т.е. обычно тремя-пятью. Иными словами, принимая во внимание цель устава и соответствующий уровень детализации, совершенно излишне разрабатывать длинный список событий — это только создаст дополнительные ограничения для выбора методологии реализации проекта. Кроме того, организации, придающие значение себестоимости, имеют тенденцию указывать для основных событий специфику бюджета ресурсов или бюджета средств
6. Участники проекта Перечисление заинтересованных сторон проекта, иными словами, круга лиц и организаций, на которых оказывает воздействие реализация данного проекта и которые сами могут воздействовать на него.
7. Окружение проекта Перечисление всех организационных факторов, характеризующих обстановку вокруг проекта и на рынке. Также необходимо указать благоприятные и неблагоприятные особенности среды, в которой проект будет выполняться (внутри и вне компании), и способность организации-исполнителя к его осуществлению, а организации-заказчика — к использованию его результатов. Далее будет показан один из эффективных способов выполнения комплексного анализа окружения и участников проекта. При использовании этого подхода сначала определяется достаточно большое число факторов, действующих в окружении проекта; они заносятся в соответствующий сектор. Затем выделяются наиболее критичные из них (прямоугольники — участники, овалы — факторы окружения)
8. Допущения относительно организации и окружения, а также внешние допущения Набор условий, которые должны быть выполнены наряду с созданием продукта проекта, для достижения результата проекта. Допущения обуславливают риски проекта; во время проекта происходит их мониторинг. Пример допущений:

    — компетенции команды проекта достаточно для выполнения предпроектного обследования;

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

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

    — увеличение стоимости проекта не более чем на 10%;

    — не менее 40% членов команды проекта, предоставляемых исполнителем, заняты на 100% в проекте.

Обратите внимание, что при составлении устава проекта ограничения формулируются со стороны организации-заказчика об организации-исполнителе и о проекте в целом
10. Объем денежных средств, выделенных на достижение бизнес-цели На данном этапе указывается сумма средств, которую организация-заказчик готова выделить на достижение сформулированной бизнес-цели проекта. Указанная сумма является результатом определения порядка величины и ошибка в оценке может составлять от -20% до +100%
11. Назначение руководителей проекта и общее определение полномочий ключевых членов проектной команды: РП, спонсор, координатор Руководитель проекта назначается уставом проекта и формально приступает к выполнению своих обязанностей на следующий день после подписания устава проекта. Руководитель, или менеджер, проекта несет основную ответственность за общее планирование, направление и контроль проекта в течение всех фаз его жизненного цикла, ставя целью получение желаемого результата в рамках утвержденного бюджета и расписания. Основная задача руководителя проекта — объединение усилий всех лиц, участвующих в проекте. Для решения этой задачи менеджер проекта наделяется полномочиями по проекту, т.е. правом отдавать функциональным лидерам проекта распоряжения, необходимые для планирования, исполнения, мониторинга, оценивания и контроля работ, которые должны быть выполнены по данному проекту. Руководство проектом также включает в себя получение информации, необходимой для планирования, мониторинга, оценивания и контроля проекта . Роль спонсора проекта обычно берет на себя (не назначается!!!) менеджер высшего звена, который действует от лица руководства компании, финансирующей или исполняющей проект. Ключевая задача спонсора заключается в обеспечении ресурсов проекта, в том числе административных, а также в обеспечении связи между проектом и руководством организации-заказчика. На проекте спонсор является лицом, принимающим те решения, которые находятся за пределами полномочий руководителя проекта, например:

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

     — назначать и утверждать менеджера проекта, а также утверждать соответствующую должностную инструкцию и порядок подчинения;

     — формировать стратегические указания для менеджера проекта по ходу отслеживания результатов проекта;

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

     — принимать решения о внесении изменений в базовую линию проекта.

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

Источник

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

Что такое бизнес-цель?

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

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

Если бизнес уже функционирует, то предприниматель тоже сталкивается с необходимостью формулировать бизнес-цель. Например, если компания реализует проект по заказу нового оборудования, его монтажу, то цель формулируется так: 

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

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

Критерии бизнес-цели

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

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

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

Примеры бизнес-целей

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

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

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

  • содержания цели;
  • размер;
  • сроки реализации – краткосрочная, среднесрочная или долгосрочная цель;

ранг в иерархии всех целей. 

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

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

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

Бизнес-цели в рамках дерева целей

Бизнес-цели являются вершиной дерева цели – набора задач, которые ранжированы по важности и приоритетности. После того как цели первого уровня выделены, можно развивать вторичные уровни. Например, компания сформулировала бизнес-задачу для своего проекта: увеличить количество покупателей до N. 

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

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

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

Увидев эти перспективы, руководство проекта формулирует маркетинговые цели. Например:

  • увеличить частоту покупок среди клиентов возрастной категории Х с доходом Y;
  • увеличить количество новых клиентов в возрасте Z;
  • увеличить частоту потребления товара – с одного раза в неделю до трех раз в неделю. 

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

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

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

  • рассказать больше об использовании товара, донести до клиентов, что товар # 1 эффективнее работает в сочетании с товаром # 2;
  • повышение узнаваемости бренда. Каждый второй потенциальный клиент должен знать название бренда, узнавать товар этой марки по фирменной упаковке;
  • проработать и донести до потенциальных покупателей имиджевые характеристики товара. 

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

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

Результат постановки бизнес-цели

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

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

Источник

Понравилась статья? Поделить с друзьями:
  • Бизнес проект детский развлекательный центр
  • Велфарм фармацевтическая компания википедия
  • Бизнес проект интернет магазина презентация
  • Вендинговый бизнес кофейные автоматы купить
  • Бургер кинг на конева в вологде часы работы