Как разработать программу внедрения

В одной из статей раздела «Просто о сложном» мы описали методику разработки проекта внедрения информационной системы ERP-класса. Не менее важен этап проектирования при внедрении других программных инструментов повышения эффективности бизнеса. Эта статья посвящена вопросам разработки проекта внедрения систем CRM — программного обеспечения управления отношениями с клиентами.

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

9 минут на внедрение системы в команде 50 человек. Кейс строительной компании

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

Реквизиты клиентской базы

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

Довольно редко в формате записи клиентской базы можно встретить реквизиты, связанные с «важностью» и «лояльностью» клиента. В лучшем случае «важность» определяется на основе объёма закупок клиента в прошлые периоды, а лояльность — как показатель стабильности этих закупок. Как будто клиент теряет «важность» от того, что мы пока не начали с ним работать, или просто не умеем его заинтересовать! Или становится не «лояльным» из-за того, что мы торгуем дорогостоящим оборудованием, которое закупается раз в несколько лет!

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

Вывод: требуемые для бизнеса поля клиентской записи, отчёты и связанные с ними бизнес-процессы должны быть проработаны на этапе разработки проекта внедрения CRM-системы.

Контрактно-ценовые условия

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

MES — пример создания и внедрения системы на предприятии (производство изделий из пластика)

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

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

• Автоматизированное назначение «Потенциала»,
• Контроль корректности,
• Оценка эффективности

придётся разрабатывать самостоятельно. Сделать это нужно на этапе разработки проекта внедрения CRM.

Планирование и отчётность по контактам

Управление контактами — важнейший функционал систем класса SFA — Sales Force Automation, который мы рассматриваем. Для того чтобы использовать все возможности указанного в заголовке раздела функционального блока, на этапе разработки проекта внедрения CRM нужно решить ряд вопросов:

1. По каким событиям нужно предусмотреть автоматическое планирование будущих контактов?
2. Какими значениями будут заполняться справочники полей «Цель» и «Результат» контакта?
3. К каким событиям должны привести разные «Результаты» контакта?
4. Какие пары «Цель» — «Результат» являются приемлемыми, а какие — требуют обсуждения для выработки дальнейших действий?
5. Какие нормативы планирования, осуществления и отчётности по контакту будут установлены и требуют контроля?

Эти и другие вопросы каждая компания решает самостоятельно на этапе разработки проекта внедрения CRM-системы.

Подготовка и отчётность по переговорам

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

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

Воронка продаж

Напомним основные принципы этой широко распространённой методики управления отношениями с клиентом:

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

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

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

Управление сложными продажами

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

1. Выявление всех лиц закупочного комитета (ЗК)
2. Сбор и анализ информации о членах ЗК
3. Определение целевого состояния отношений с членами ЗК.
4. Формирование стратегии, сценария переговоров и аргументации по каждому члену комитета.
5. Реализация плана при постоянном анализе новой информации.

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

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

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

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

Информация, накапливаемая в CRM-системе, не будет полезной для анализа, если в компании не выработаны правила заполнения электронных документов — карточек клиентов, записей о контактах, других форм. Эти правила должны быть закреплены в CRM путём

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

Эти правила, отчёты и регламенты их использования должны быть проработаны на этапе разработки проекта внедрения CRM-системы.

ПР1_УП04. Дубров_ПрокатАвто. Практическая работа 1 Разработка сценария внедрения программного продукта

Единственный в мире Музей Смайликов

Самая яркая достопримечательность Крыма

Скачать 268.97 Kb.

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

Цель работы

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

Задачи

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

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

Бизнес-цель внедрения информационной системы

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

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

Устав проекта

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

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

• функцию постановки задачи;

• функцию повышения дисциплины;

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

1. Обоснование выполнения уникальной задачи развития.

2. Цели, задачи и результаты.

3. Имя и фамилию PM, границы его ответственности и полномочия.

4. Определение и структуру продукта.

5. Интересы и ожидания участников.

6. Критерии успеха.

7. Принципы организации и управления проектом

В качестве предметной области выбрана тема «Прокат автомобилей».
1. Этап разработки раздела «Общие сведения»

 Полное наименование ИС: «КарШэринг».

 Шифр темы: 00001.

 Предприятие-разработчик системы: «Лаборатория ИС», ул. Пушкина 10, 36-37-80

 Предприятие-заказчик системы: ООО «ПрокатАвто».

 Система создается на основании технического задания (ТЗ). ТЗ на АС является основным документом, определяющим требования и порядок создания автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие. Кроме того, при создании системы используются ГОСТ 34.602-89 “Техническое задание на создание автоматизированной системы”.

 Плановый срок начала работ: 05.05.2022.

 Плановый срок окончания работ: 05.05.2023.

 Автоматизируемая система создается на коммерческой основе.

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

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

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

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

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

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

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

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

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

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

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

Описание автоматизируемых процессов, информационные потоки автоматизируемых процессов

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

С
хема информационных потоков процесса показана на рисунках 2,3,4.
Рис.2 Схема информационных потоков Клиент (заказ)

Рис.3 Схема информационных потоков Клиент (отзыв/запрос)

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

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

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

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

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

 уменьшению времени по учету данных о сотрудниках/клиентах;

 уменьшение времени на формирование/обработку отчетов, заявок, отзывов;

 уменьшению времени на мониторинг транспортных средств;

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

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

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

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

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

 Просматривать данные таблиц, при необходимости редактировать их.

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

 Создавать заявки при проблемах с ПО или оборудованием у сотрудников.

 Создавать отчёты о проделанной работе.
При работе с системой клиенты должны решать следующие задачи:

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

 Оставлять отзывы об услугах.

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

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

Все отчеты должны оформляться в едином стиле.

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

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

 данные о сотрудниках;

 данные о клиентах;

 данные о транспортных средствах;

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

• Операционная система Windows 7 и новее
• Веб-браузер Google Chrome версии 100 и новее

• Операционная система Android 5 и новее

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

 1 Гбайт дисковой памяти;

 принтер формата А4.
5. Этап разработки раздела «Стадии и этапы разработки»

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

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

 разработка технического задания;

 внедрение.
6. Этапы разработки

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

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

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

 разработки логической и физической моделей данных;

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

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

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

УСТАВ ПРОЕКТА
Разработать устав проекта, согласно требованиям, предъявляемым к нему
Таблица 1. Требования к уставу проекта

1. Создать 1 интерактивную базу данных;
2. Создать 1 сайт;
3. Создать 1 мобильное приложение для Android.

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

• Создание интерактивной базы данных 05.05.2022 – 05.06.2022
• Предпроектная подготовка к созданию сайта -05.06.2022 – 19.06.2022
• Разработка и согласование дизайна сайта — 19.06.2022 – 03.07.2022
• Верстка сайта 03.07.2022 – 03.08.2022
• Наполнение сайта контентом 03.08.2022 – 10.08.2022
• Тестирование сайта – 10.08.2022 – 31.08.2022
• Официальный запуск сайта – 31.08.2022 – 15.09.2022
• Предпроектная подготовка к созданию мобильное приложения – 15.09.2022 – 30.10.2022
• Разработка и согласование дизайна сайта – 30.10.2022 – 30.11.2022
• Программная часть проекта – 30.11.2022 – 30.03.2023
• Тестирование приложения – 30.03.2023 – 30.04.2023
• Официальный запуск приложения – 30.04.2023 – 05.05.2023

— компетенции специалистов для создания дизайна сайта и приложения достаточно;

— компетенции специалистов для вёрстки сайта достаточно;

— компетенции специалистов для разработки мобильного приложения на базе Android достаточно.

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

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

Источник: topuch.com

Внедрение программного обеспечения (лекция №7)

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

3.

Внедрение программного обеспечения требует действий в трёх следующих плоскостях работ:
• Выделение критических, с точки зрения общего результата, процедур в деятельности
организации.
• Расширение нормативной базы организации путём включения в неё регламентов,
описывающих порядок выполнения процедур автоматизируемых процессов.
• Выполнение работ по общей стандартизации существующей деятельности организации.
В зависимости от потребностей Заказчика,
автоматизацию учета на предприятии возможно
осуществить 3 методами:
Обычная установка программного обеспечения;
Стандартное внедрение;
Проектное внедрение.
Проектное внедрение
состоит из следующих этапов:
обследование;
проектирование;
разработка;
внедрение и опытная
эксплуатация.

4.

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

5.

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

6.

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

7.

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

8.

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

9.

Уровни внедрения ПО

10.

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

11.

Разработка и внедрение информационной
системы

12.

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

13.

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

14.

Структура
системы
среды
информационной
Обобщенная структура любой ИС может быть
представлена двумявзаимодействующими частями:
функциональной
части,
включающей
прикладные программы, которые реализуют
функции прикладной области;
среды или системной части, обеспечивающей
исполнение прикладныхпрограмм.
С этим разделением тесно связаны две группы
вопросов стандартизации:
стандарты
интерфейсов
взаимодействия
прикладных
программ
со
средой
ИС,
прикладной
программный
интерфейс
(Application Program Interface — API);
стандарты интерфейсов взаимодействия самой ИС
с внешней для нее средой (External Environment
Interface — EEI).

15.

Спецификации
внешних
интерфейсов среды — это
точные
описания
всех
необходимых функций, служб и
форматов
определенного
интерфейса.
Совокупность
таких описаний составляет
эталонную модель открытых
систем (Reference Open System
Model).
Эта модель используется более 20 лет и определяется
системной сетевой архитектурой (SNA), предложенной IBM
в 1974 году. Она основана на разбиении вычислительной
среды на семь уровней, взаимодействие между которыми
описывается соответствующими стандартами, и
обеспечивает связь уровней вне зависимости от построения
уровня в каждой конкретной реализации

Источник: ppt-online.org