Видение проекта пример. Видение компании. Информационный состав видения

  • 13.11.2019

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

Предприятие может быть успешным долгое время, если сотрудники предприятия идентифицируют себя с ним. Они должны знать, для чего работает их предприятие, какой смысл несет его деятельность. И если они знают ответ, и ответ звучит позитивно, то на эмоциональном уровне они готовы приложить свои усилия для достижения цели. Так как у них теперь есть видение дела. И происходит самоидентификация с этим делом. Зачем мы делаем то, что мы сегодня делаем? Где мы видим себя через 5-10 лет?

Модель видения

Д. Коллинз описывает следующую модель видения. Она включает в себя две важные составляющие: – ключевая идеология (core ideology) – воображаемое будущее (envisioned future). Ключевая идеология состоит из ключевых ценностей и ключевого назначения (миссии). Воображаемое будущее обязательно включает в себя цели (См. Целеполагание), содержащие вызов для компании и четкое описание результатов достижения этих целей. Видение – это не абстрактное желание. Оно должно строиться на реальной основе и соответствовать реальности. Уточнению видения в компании благоприятствуют разработки новых продуктов, введение новых технологий, реорганизация структур. Это все ведет к уточнению смысла и совместной работы сотрудников. Здесь играет роль каждый сотрудник. Видение компании, бизнеса – это больше, чем просто обобщение главных целей компании. Однако цели и миссия имеют много общего. Они должны соответствовать друг другу. Часто цели выводятся из видения и миссии бизнеса. И если одно соотносится с другим, тогда видение, миссия и цели бизнеса выглядят реалистичными. Правдоподобность – это ключевой принцип формулирования видения бизнеса. Здесь предполагается, что в формулировке видения учитывается мнение сотрудников; видение постоянно подтверждается конкретными действиями со стороны руководства; этим достигается соответствие ежедневного рабочего расписания, целей и видения.

Видение и миссия

Видение – это наше представление о будущем, которое наступит, даже если нас там не будет. Миссия – это наше место в том будущем, которое мы видим. Видение – это то, где вы хотите оказаться. Оно может быть основано на ценности в экономическом смысле, но необязательно. Конкретная цель – «мы хотим достичь оборота в $1 млн.» может стать «мы хотим иметь наибольшую долю рынка в нашей отрасли». Видение отличается от миссии тем, что оно сфокусировано как на компанию саму по себе, ее сотрудников, и на внешний мир – клиентов. Миссия же почти всегда направлена во вне, на клиентов компании. Но бывают случаи, когда миссия и видение компании сформулированы в одном и том же предложении. Так, на сайте компании Sony Ericsson под заголовком «Миссия» описывается видение:«Our vision is to become THE communication entertainment brand. We inspire people to do more than just communicate. We enable everyone to create and participate in entertainment experiences. Experiences that blur the lines between communication and entertainment. Наше видение: стать символом связи-развлечения. Мы вдохновляем людей на нечто большее, чем просто общение. Мы даем возможность каждому создавать и получать опыт развлечения. Этот опыт стирает границы между развлечением и общением» .

Примеры видения

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

Шаги, которые необходимо пройти для формирования документа "Видение":

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

Для описания проблем предлагается шаблон , показанный в табл. 7.1 .

Идентификация совладельцев предполагает поиск и фиксацию интересантов проекта - представителей Заказчика и Исполнителя, инвесторов, внешних экспертов и пр.

Определение границ системы представляет собой нетривиальный процесс. Для этого используют контекстные диаграммы (см. материалы "Расширенный анализ требований. Моделирование"). RUP в поиске границ предлагает отталкиваться от факторов и вариантов использования.

Среди источников ограничений обычно выделяют:

  • Политические,
  • Экономические,
  • Среды,
  • Технические,
  • Выполнения,
  • Системные.

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

Шаблон документа "Vision" RUP содержит следующие основные разделы :

  1. Введение
  2. Позиционирование
  3. Описания совладельцев и пользователей
  4. Краткий обзор изделия
  5. Возможности продукта
  6. Ограничения
  7. Показатели качества
  8. Старшинство и приоритеты
  9. Другие требования к изделию
  10. Требования к документации
  11. Приложение.

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

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

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

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

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

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

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

Раздел "Старшинство и приоритеты" ранжирует сформулированные ранее требования и возможности системы по степени важности, очередности реализации и т.п.

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

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

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

Видение / рамки в MSF

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

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

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

Заказчик:
DABCC.COM

Исполнитель:
Douglas Brown, Owner

Проект:
Развертывание Citrix® MetaFrame® Access Suite

Стадия проверки концепции проекта предназначена для определения возможностей продлагаемого развертывания MetaFrame Access Suite с точки зрения достижения видения проекта. В процессе проверки концепции создан прототип среды MetaFrame Access Suite вместе со всеми необходимыми приложениями, принтерами и т.п. Приложения были тщательно протестированы для проверки их работоспособности в терминальной среде MetaFrame XP/Terminal Server. По каждому пункту задокументированы результаты и внесены необходимые корректировки. Этот документ является итоговым отчетом по процедурам проверки концепции.

Этот документ разделен на следующие разделы:

  • Спецификация среды
  • Процедура создания среды
  • Тесты
  • Корректировки тестов
  • Заключение

1. Спецификация среды

1.2. Аппаратное обеспечение

Имя: DB2KCTX1
Модель: Compaq ML 530
Роль: Citrix MetaFrame XP Server




48x CDROM, второй - под Compaq Internal DLT 20/40

Дисковый контроллер - Smart Array 4200 4-канальный контроллер RAID 5
Имя: DB2KWEB1
Модель: Compaq ML 530
Роль: Web Interface Web Server
Form Factor – монтируемый в стойку
Процессор – 2 х 933MHz, Pentium III Xeon, 256KB level 2-Advanced Transfer Cache.
Память – 1 GB 133 MHz ECC SDRAM, расширяемая до 4GB с использованием модулей 512 MB
Сетевой адаптер - NC3123 Fast Ethernet NIC PCI 10/100 controller
Отсеки под диски – 4 отсека 5.25" для съемных дисков и один 1.44 MB флоппи-привод. Один использован под привод
48x CDROM, второй - под Compaq DLT 20/40
Дисковые накопители - всего 218.4 GB Maximum Internal Hot Plug Storage Ultra2. Установлены три диска 18.2 GB Hot Plug Ultra 3
Дисковый контроллер - Smart Array 5300 RAID ADG, настроен на RAID 5
Интерфейсы - один порт RJ-45 Ethernet, два последовательных, один параллельный, клавиатуры, мышь, видео, внешний SCSI

1.3. Среда операционных систем

Конфигурация домена
Active Directory или NT Domain? Active Directory
(NT Domains) Модель домена (Single domain, Master domain, Multiple-master, etc.): -
(Active Directory) Режим (native / mixed)? Native
(Active Directory) Имя дерева: DABCC.COM
(Active Directory) Имя домена: DABCC.COM
(Active Directory) Пространство имен DNS: DABCC.COM
(Active Directory) Внутреннее пространство имен: DABCC
Имена серверов DNS: DB2KAD1, DB2KAD2
Имена серверов WINS: DB2KAD2
Имя сервера DHCP: DB2KAD2

Адреса TCP/IP
Укажите информацию об адресах IP вашей сети
Network Address: 192.168.1.0
Subnet Mask: 255.255.255.0
Gateway: 192.168.1.254
Primary WINS: 192.168.1.1
Secondary WINS: Нет
Primary DNS: 192.168.1.1
Secondary DNS: 192.168.1.2
Укажите адреса серверов, перечисленных в разделе "Аппаратная среда":
DB2KAD1 192.168.1.5
DB2KAD2 192.168.1.6
DB2KFS1 192.168.1.71
DB2KWEB1 192.168.1.8
Укажите адреса IP сетевых принтеров
HP 4M 192.168.1.15
HP 4000 192.168.1.16
HP 4000 192.168.1.17
HP LaserJet 4050 Color 192.168.1.18
HP OfficeJet 720 192.168.1.19
Укажите диапазон DHCP:
Диапазон DHCP: с 192.168.1.100 по 92.168.1.200
Список OU
Наименование Описание
Built-in Default OU
Computers OU для конечных пользователей
DABCC Users OU для пользователей и групп DABCC.COM
Domain Controllers OU для контроллеров домена Windows 2000 Active Directory. Включает в себя DB2KAD1 и DB2KAD2.
Foreign Security/Principles Default OU
Servers OU для серверов Windows NT/2000. Включает: DB2KFS1 и DB2KWEB1
Users OU по умолчанию для пользователей и групп Active Directory
Информация о групповых политиках (если есть)
Используются политики WinNT или Win2000? Win2000
Размещение файлов политик -
Пользователи и группы, затрагиваемые политиками Administrators, Users


1.4. Скрипты входа

net use h: \dabcc\\dfsroot\users\%username%

Logon_admins.cmd

net use j: \dabcc\\dfsroot\applications
net use k: \dabcc\\dfsroot\drivers
net use o: \dabcc\\dfsroot\citrix
net use p: \dabcc\\dfsroot\public

1.5. Среда печати

Имя принтера Имя сервера печати Драйвер
HP4M DB2KFS1 HP 4M
HP4000West DB2KFS1 HP 4000
HP4000East DB2KFS1 HP 4000
HPColor DB2KFS1 HP LaserJet 4050 Color
HPOfficeJet DB2KFS1 HP OfficeJet 720

1.6. Клиентская среда

2. Процедура создания среды

Сервер Citrix MetaFrame Access Suite и все другие серверы, использованные на этапе проверки концепции, настроены в сооветствии с методологией D&D Consulting, включая безопасность и оптимизацию сервера. Это делается на тот случай, если проверка концепции будет успешной, то среда сервера будет основой для промышленного внедрения MetaFrame Access Suite в промышленную среду.

Подробности относительно проектирования MetaFrame XP, MetaFrame Secure Access Manager, Web Interface или Secure Gateway см. в документации, предложенной D&D Consulting.

Ниже приведен основной список шагов по созданию сервера MetaFrame XP:

  • Установка операционной системы сервера, последнего сервис-пака и хотфиксов
  • Установка необходимых служб и удаление ненужных служб
  • Настройка сетевой и доменной идентификации сервера
  • Изменение службы SNMP так, чтобы сообщество “public” имело право"чтение и запись"
  • Настройка всех сетевых адаптеров сервера на 100 Mbps и Full Duplex
  • Настройка локальной безопасности на сервере Citrix
  • Активация сервера лицензирования Terminal Services Licensing и клиентских лицензий TS CAL
  • Инсталляция последнего Feature Release на Citrix MetaFrame XP и последнего сервис-пака
  • Настройка лицензирования Citrix на сервере
  • Установка Citrix Installation Manager (если требуется)
  • Установка Citrix Resource Manager (если требуется)
  • Настройка на сервере SpeedScreen
  • Настрока соединений
  • Настройка ICA Client Update Configuration
  • Настройка на сервере оптимизации
  • Иолирование сервера с использованием прав доступа NTFS и системных политик
  • Настройка печати на сервере
  • Установка и настройка приложений
  • Настройка SpeedScreen для индивидуальных приложений
  • Публикация приложений
  • Создание диска аварийного восстановления
  • Установка остальных компонентов (MetaFrame Conferencing Manager, Web Interface, Secure Gateway, и т.п.)
  • Проверка сервера и приложений

2.2. Процедура инсталляции приложений
Напишите подробную инструкцию инсталляции каждого приложения, которое будет проверяться на этапе проверки концепции.

3.0. Тесты

4.0 Корректировка тестов

5.0 Заключение

После анализа результатов тестирования и необходимых корректировок, D&D Consulting и DABCC.COM определили, что получены достаточные основания для продолжения изначально спланированного проекта.

Формирование видения

Прототипирование

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

Метод RAD - один из наиболее известных способов быстро создавать прототипы 1) .

RAD базируется на следующих базовых принципах:

  • Эволюционное прототипирование;
  • CASE-средства, как основной инструмент, включая возможности прямого и обратного проектирования и автоматической генерации кода;
  • Высококвалифицированные специалисты, хорошо владеющие развитыми инструментальными средствами;
  • Интерактивный JAD-метод, в котором общение совмещается с разработкой в режиме online;
  • Жесткие временные рамки, как противоядие от "расползания границ" проекта: если команда не укладывается в срок - функционал сужается.

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

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

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

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



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

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

Всегда ли нужно создавать документ "Концепция"? Следует ли разделять видение и границы?

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

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

Поэтому этап формирования концепции важен, но он предъявляет и к Заказчику и к Исполнителю достаточно высокие требования: Заказчик должен выделить ресурсы и быть готовым к трудозатратам на совместный поиск решений; Исполнитель должен обладать достаточной квалификацией как в сфере IT-, так и в сфере управления предприятиями, чтобы разрабатываемое средство автоматизации действительно принесло пользу. Все вышесказанное ничуть не исключает возможность работы без концепции: либо речь идет о небольшом проекте, закладывать в бюджет которого этап выработки концепции просто нерентабельно, либо Заказчик сам обладает достаточной квалификацией, чтобы сформулировать требования к АИС, имея "концепцию в голове" и время для консультирования Разработчика.

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

Рассмотрим основные требования к выработке концепции, заложенные в отечественных ГОСТ, методологиях RUP и MSF.