35
Бизнес-процессы
0
3
3
0
1
2
Задачи
3
2
3
1
3
1
Email-рассылка
1
2
1
1
1
0
Email-клиент
1
1
1
1
3
1
Настройка
интерфейса
1
3
1
1
1
0
Права доступа
2
2
1
1
2
1
Отчетность
1
2
1
1
3
1
Веб-формы
0
1
2
3
0
0
API
2
1
2
3
3
0
Возможность
доработки
0
3
1
1
3
0
Social CRM
0
0
0
1
0
0
Разделение на
лиды и контакты
Нет
Нет
Да
Нет
Нет
Нет
Вариант поставки
SAAS и
Stand
Alone
SAAS
SAAS и
Stand
Alone
SAAS
SAAS и
Stand
Alone
SAAS
Качество
документации
Высокое
Высоко
е
Среднее
Средне
е
Низкое
Средне
е
Уровень
сложности
системы
Низкий
Высоки
й
Высоки
й
Низкий
Высоки
й
Низкий
В верхней строке таблицы прописаны названия CRM-систем, а в левом
столбце — названия функций. На пересечении будет дана оценка по 4-бальной
шкале, где:
0 — функция отсутствует в системе
1 — функция присутствует, но в силу сложности или наоборот
примитивности, ею нельзя пользоваться
2 — функцией возможно пользоваться, но необходимы усилия со стороны
программиста и/или консультанта
3 — функцией возможно пользоваться из коробки при определенной
подготовке (прочитав мануал).
Для рассматриваемой задачи необходима только одна основная функция —
организация сбора и анализа информации по продажам с возможностью
составления отчетов. В рассмотренных системах данные возможности
присутствуют, но одновременно вместе с необходимыми функциями в пакете
программного обеспечения могут приобретаться и многие другие, которыми,
36
возможно, менеджеру отдела продаж воспользоваться и не придется, так как одни
функции явно избыточны, другие продублированы уже используемым
программным обеспечением.
Поэтому более целесообразным предоставляется вариант самостоятельной
разработки с учетом всех тонкостей деятельности предприятия, в частности,
процесса по расчету показателей экономической устойчивости.
Под стратегией автоматизации понимаются базовые принципы,
применяемые при автоматизации организации. В нее могут быть включены
следующие компоненты:
• Направления деятельности компании и порядок, в котором они будут
автоматизированы;
• Методики автоматизации: комплексная автоматизация, хаотичная по
направлениям, участкам;
• Утвержденная техническая политика – совокупность внутренних
стандартов, реализованных на предприятии;
• Ограничения: временные, финансовые и т.д.;
• Способы контроля изменений плана.
Автоматизация становится одним из способов достижения стратегических
бизнес - целей, и не является обычным процессом, развивающимся по своим
внутренним законам. В любой стратегии автоматизации должна быть заложена
стратегия бизнеса компании: ее миссия, направления и модель бизнеса. Поэтому
стратегия автоматизации – это некий план, согласованный по срокам и целям со
стратегией компании.
Параметрами отбора стратегии автоматизации в компании становится
расширение и добавление новых возможностей системы после его внедрения,
рентабельность использования системы, ограничения временных затрат. Именно
поэтому рассмотрим возможность использования одной из 3 стратегий
автоматизации:
• Хаотичная автоматизации, предполагающая установку частей ИС по
мере доступности. Характеризуется как «заплатка». Является самым худшим
37
вариантом с точки зрения ощутимого эффекта. Не имеет стратегического плана
развития ИС. Разрабатывается зачастую для решения сиюминутных задач;
• Автоматизация по участкам, определяющая процесс автоматизации
выбранных производственных или управленческих подразделений, которые
можно объединить по функциональному признаку. Внедрение вязано с большой
трудоемкостью, а для качественной реализации стратегии необходимы
стратегические и оперативные планы. Подобный подход выбирается в случае,
если инвестиционные ресурсы ограничены и не потянут полную автоматизацию
компании, а реализованная автоматизация участка показывает неплохие
результаты;
• Автоматизации по направлениям, подразумевающая автоматизацию
отдельных групп, бизнес-процессов (направлений) - изготовление, продажу,
управление финансами.
Если мы меняем объект, то нужно менять и предметную область.
Выбор системы зачастую связан с видом услуг и составом затрат.
Реализовав систему, мы получаем “конструктор” АРМов.
Хаотичная стратегия не актуальна, так как использование ИС
рассматривается в долгосрочной перспективе, а также возможно расширение и
добавление технических возможностей системы. Автоматизация по участкам
включает автоматизацию некоторых отделов компании. Метод автоматизации по
направлениям самый подходящий, поскольку в случае его использования будет
реализована автоматизация единого направления – учета взаимоотношейний с
клиентами.
Стратегия автоматизации изначально должна соответствовать задачам и
стратегии бизнеса. В понятие стратегии обычно включаются пути достижения
этого соответствия.
В случае для предприятия подходит стратегия автоматизации «по
участкам», т.к. автоматизируется отдельное подразделение (участок) – отдел по
работе с клиентами.
38
Способы внедрения ИС – это совокупность действий от определения и
формализации решения об использовании ИС до момента, когда ИС уже будет
использоваться в компании. Есть следующие способы приобретения ИС:
• Создание (самостоятельно или на заказ);
• Покупка системы (отечественной или зарубежной ИС);
• Покупка и последующая доработка (самостоятельно или на заказ);
• Арендование.
Опишем детально все способы на предмет их применения к автоматизации
указанной ранее задачи.
При покупке готового решения важно выбрать такое решение, которое
сможет 100% соответствовать схемам построения бизнеса. Это довольно сложно,
поскольку разработчики систем автоматизации хотят угодить большинству
потенциальных клиентов и создают системы, которые изначально перегружены
лишним функционалом, за который в любом случае надо платить, либо система
является каркасом для реализации решения под отдельного потребителя. Эти
варианты не подходят для решения указанной ранее задачи, поскольку покупка
готовой ИС для автоматизации по направлениям становится невыгодным с точки
зрения конечной стоимости такой системы.
Купленная ИС также не подходит из-за ряда недостатков и минимального
функционала, плохо проработанной системы будущего развития ИС, длительного
срок адаптации под требования предприятий, так же необходимости постоянного
обращения в службу поддержки.
Заказ разработки у другой IT-компании дает возможность получить ИС,
которая будет удовлетворять бизнес-правилам компании в настоящий момент. Но
в процессе изменения бизнес-процессов может потребоваться ее переработка, что
выльется в дополнительные затраты на переработку уже созданной ИС.
Покупка и доработка имеет место, если объем доработки не так велик,
подобная доработка становится возможна в рамках модели ядра ИС, что может
вызвать затруднения из-за отсутствия полноценной документации. Вариант с
арендой ИС имеет следующие преимущества:
39
• Оптимизирует инновационные возможности компании благодаря
взаимодействию и партнерству с поставщиками мирового уровня, которые уже
накопили огромный интеллектуальный потенциал и имеют богатый опыт
разработки;
• Поддерживает большую гибкость компании в момент очередного
изменения рыночной ситуации или потребительских предпочтений: удобнее и
дешевле стать сотрудничать с новыми поставщиками, у которых уже есть
необходимые технические возможности и ресурсы, чем полностью менять
внутреннюю деятельность компании, заменяя одни мощности и ресурсы на
другие;
• Ускоряет процесс приобретения новых ресурсов и навыков;
• Дает возможность подробнее останавливаться на тех операциях,
которые реализуются внутри самой компании, а также тех, которые лучше
изначально сохранить под ее контролем.
Однако в таком случае компания рискует вывести за свои пределы
значительную часть деятельности и может потерять некоторые собственные
ресурсы и возможности. И тогда компания утратит виды деятельности, которые
гарантировали ей успех на рынке в течение некоторого времени.
Поэтому ИС будет создаваться в компании собственными силами,
поскольку в штате фирмы есть квалифицированные сотрудники, способные
разработать и внедрить данную ИС. Создание собственной системы обязывает
компанию иметь специалистов, способных реализовать анализ бизнес-процессов,
спроектировать и внедрить систему для их автоматизации. Так как
автоматизируется одно не самое объемное направление деятельности,
имеющимся сотрудникам не составит особого труда реализовать весь комплекс
работ по созданию проекта, разработке и внедрению системы автоматизации.
Полученная в итоге ИС будет сочетать в себе необходимый функционал,
учитывать основные особенность работы, а также пожелания и требования
сотрудников компании, поскольку будет изначально являться уникальным
продуктом, позволяющим оперативно дорабатывать функциональность в
соответствии с требованием работников компании.
40
2 Разработка проекта автоматизации анализа
конкурентоспособности товара
2.1 Этапы жизненного цикла проекта автоматизации
Методология проектирования ИС включает в себя описание процесса
создания и сопровождения систем в виде жизненного цикла (ЖЦ) ИС,
отождествляя его с некоторой последовательностью стадий и исполняемых на них
процессов. Для каждой стадии выявляется состав и последовательность
производимых работ, итоговые результаты, методы и средства, нужные для
реализации работ, ответственность и роль участников и т.д. Подобное
формальное описание ЖЦ ИС дает возможность спланировать и подготовить
процесс совместной разработки и поддерживать управление этим процессом.
Жизненный цикл (ЖЦ) ИС представляется, как ряд событий, случающихся
с системой с момента ее внедрения и до окончания использования.
Модель ЖЦ отражает различные состояния системы, от момента
возникновения необходимости в данной ИС и до момента ее окончательного
вывода из эксплуатации. Модель жизненного цикла представлена некой
структурой, которая содержит процессы, действия и задачи, реализуемые в ходе
создания, работы и сопровождения ПО в течение всей жизни системы, от
выявления требований до окончания ее использования.
Сегодня известны и применимы следующие модели жизненного цикла:
• Каскадная модель включает в себя последовательную реализацию
всех этапов проекта в заранее определенном порядке. Начало следующего этапа
говорит о полном завершении работ на предыдущем этапе.
• Поэтапная модель с периодичным контролем. Создание ИС
реализовано в виде итераций с циклами обратной связи между этапами.
Межэтапные проверки позволяют учесть реально существующее взаимовлияние
итогов разработки на различных этапах; ЖЦ каждого из этапов продлевается на
весь срок разработки.
• Спиральная модель. На любом витке спирали выполняется генерация
очередной версии продукта, корректируются требования проекта, выражается его
41
качество и планируются работы уже следующего витка. Особое внимание при
этом обращается на начальные этапы разработки - анализ и проектирование, где
возможность создания тех или иных технических решений обосновывается и
проверяется благодаря построению прототипов.
Каскадный подход отлично зарекомендовал себя в процессе создания
относительно простых ИС, когда в самом начале разработки можно с большой
точностью и полнотой составить все требования к системе. Главным недостатком
такого подхода является то, что основной процесс разработки системы не может
полностью уложится в такие жесткие рамки, постоянно есть потребность в
возврате к уже завершенным этапам для уточнения или изменения ранее
принятых решений. В итоге реальный процесс разработки ИС становится
соответствующим поэтапной модели с периодичным контролем.
Для разработки системы взаимоотношенйи с клиентами выбираем
каскадную модель жизненного цикла.
Все стадии создания системы предусматривают выполнение некоторого
объема работ, представляемых в виде процессов ЖЦ. Процесс выражается как
совокупность объединенных действий, изменяющих входные данные в выходные.
Описание любого процесса состоит из перечня решаемых задач, исходных данных
и итоговых результатов.
Есть целый ряд стандартов, определяющих ЖЦ ПО, а в отдельных случаях
и процессы разработки.
Среди самых известных стандартов выделяют следующие:
• ГОСТ 34.601-90 - распространяется на АИС и указывает в себе
стадии и этапы их создания. Также в нем имеется описание содержания работ на
всех этапах. Стадии и этапы работы, отраженные в стандарте, зачастую
соответствуют каскадной модели жизненного цикла.
• ISO/IEC 12207:1995 - стандарт на процессы и реализацию
жизненного цикла. Применяется ко всем видам заказного ПО. Стандарт не имеет
описания стадий, фаз и этапов.
• Custom Development Method по созданию прикладных ИС -
технологический материал, углублённый до уровня заготовок проектных
42
документов, которые рассчитаны на применение в проектах совместно с Oracle.
Используется CDM для типовой модели ЖЦ (имеются все работы/задачи и
этапы), а также для случаев "быстрой разработки" (Fast Track) или "облегченного
подхода", которые будут оптимальны в малых проектах.
• Rational Unified Process (RUP) включает в себя итеративную модель
разработки, имеющую четыре фазы: старт, анализ, создание и использование. Все
эти фазы могут быть разделены на этапы (итерации), по итогу которых имеется
версия для внутреннего или внешнего использования. Реализация четырех
основных фазы считается циклом разработки, и любой такой цикл завершается
созданием версии системы. В случае, если работа над проектом не прекращается
и после этого, полученный продукт продолжает оптимизироваться и снова
проходит те же фазы. Суть реализации в рамках RUP - это разработка и
сопровождение моделей на базе UML.
• Microsoft Solution Framework (MSF) похож на RUP, так же имеет
четыре фазы: исследование, построение, создание, стабилизация, является
итерационным, включает в себя применение объектно-ориентированного
моделирования. MSF в отличии от RUP в сильнее ориентирован на создание
бизнес-приложений.
• Extreme Programming (XP). Экстремальное программирование (самая
молодая среди остальных методологий) было реализовано в 1996 году. В основе
методологии лежит командная работа, четкая коммуникация между
исполнителем и заказчиком в течение всего срока проекта, а сама разработка
реализуется методом последовательной доработки прототипов.
• Стандарт ISO/IEC серии 15288.
При выборе стандарта основным определяющим фактором является более
полное и подробное описание работ на стадиях и этапах разработки
АС(автоматизируемых систем). Стандарт ISO/IEC 12207 не содержит подробное
описание работ на разных стадиях и этапах разработки АС. Стандарт CDM
рассчитан на использование в проектах с применением Oracle технологий,
который в данном проекте не используются. Стандарт MSF, как было ранее
сказано, в большей степени ориентирован на разработку бизнес-приложений.
43
Первый этап включает исследование проблемной области, подготовку
требований заказчика. Итогом данного этапа считается ТЗ, утвержденное с
каждой заинтересованной стороной.
В рамках второго этапа, исходя из ТЗ, создаются требуемые проектные
решения. По итогу получается готовый комплект проектный документов [42].
Третий этап включает создание проекта, к примеру: подготовка ПО исходя
из решений по проекту завершенного этапа. Методы создания тут не так важны.
Итогом реализованного этапа выступает полноценное и готовое ПО.
Четвертый этап включает проверку созданного ПО на соответствие всем
указанным в ТЗ требованиям заказчика. Реальная эксплуатация может показать
скрытые или неявные ошибки и проблемы, которые всплывают лишь в процессе
реальной работы АИС.
Пятый этап - это сдача всего проекта, и тут основным является процесс
представления продукта заказчику так, чтобы он понял, что все реализовано на
100%.
Основные плюсы каскадной модели:
1. Каждый этап включает совокупность документов по проекту,
которые отвечают требованиям полноценности и законченности. На итоговых
этапах создается инструкция для пользователя, описывающая все включенные
стандартами виды обеспечения АИС (ПО, ИО, ТО и т. д.);
2. Очередность реализации этапов работ помогает лучше
распланировать сроки окончания и возможные затраты.
Минусы каскадной модели:
1. Есть задержки в рамках выявления контрольных результатов;
2. Недоработки и нюансы на любом из этапов становятся известны,
зачастую, на следующих этапах работ, что ведет к неизбежному возврату;
3. Трудности параллельного ведения всей деятельности.
ЖЦ итерационной модели разделен на итерации, любая из которых
становится проектом в миниатюре, поскольку имеет все этапы создания ПО
(подготовка требований, выделение спецификаций, реализацию, проверку и
44
внедрение). Но в границе единой итерации готовиться не весь проект, а лишь
отдельная его версия (часть).
Задача любой такой итерации — получить версию ПО, которая состоит из
обновленных возможностей, созданных в рамках имеющихся итераций, и
функциональности всех пройденных итераций. Итогом конечной итерации
становится требуемая функциональность разработки. Сроки и затраты, которые
нужны для реализации итоговой версии, зачастую изначально не
устанавливаются, поскольку не отражается совокупный объем работ и требования
готовятся по ходу реализации [4].
Позитивные нюансы итерационной модели заключаются в том, что
корректировки между этапами дают меньшую трудоемкость реализации в
отличии от каскадной модели.
Негативными факторами итерационной модели можно назвать:
• Длительность прохождения каждого этапа равно длительности всей
разработки;
• Множество итераций часто ведет к не состыковкам в процессе
внедрения проектных решений и изготовления документации;
• Сложность архитектуры;
• Трудности использования документов по проекту в процессе
установки и использования считаются причинами переделки системы с нуля [5].
Спиральная модель, как и итерационная, имеет похожий процесс
реализации АИС. Но в данном случае очень важно выполнение стартовых этапов
– изучения и проектирования, где проводится обоснование и проверка
применимости технических решений методом создания прототипа.
Каждая итерация – это конечный цикл реализации, ведущий к выпуску
некой версии продукта, обновляемого от итерации к итерации, чтобы по итогу
стать конечной системой, как показано на рис. 4.
Преимущества спиральной модели ЖЦ:
• Активное изучение рисков, ведущее к минимизации и раннему
выявлению сложных рисков;