45
на покупку программного продукта (или подписки на него), так и источники
окупаемости данного решения за счет возможности заранее видеть проблемные
участки и принимать по ним решение.
1.4. Обоснование проектных решений
1.4.1. Обоснование проектных решений по информационному
обеспечению
Решения по информационному обеспечению затрагивают в первую очередь
решения о нормативно-справочной информации, на базе которой ведется
планирование, и об уровне детализации, используемой при планировании. В
данном проекте предлагается планировать на базе существующих справочников,
статистики информационной системы, существующих правил классификации
клиентов – планирование в понятных, знакомых пользователям терминах, и
одновременная с этим задача по подготовке данных к планированию и
повышению качества информации перед началом планирования.
Раздельное планирование продаж крупных клиентов, дающий наибольший
вклад в выручку - оправдано для компании работающей на рынке B2B, поскольку
таких клиентов относительно немного, и поскольку данные клиенты
обеспечивают значительный вклад в общей результат компании, а значит, в их
отношении следует применять индивидуальный подход.
Индивидуальное раздельное планирование продаж крупным клиентам в
рамках исполнения гособоронзаказа (ГОЗ) по отдельным ГОЗ - оправдано, по
крайней мере, по трём причинам. Во-первых, данные заказы в основном имеют
строгий перечень продукции, строгие сроки исполнения, строгие требования к
качеству, а значит, эти заказы надежны, и известно наперёд, что именно
потребуется. Во-вторых, нарушение исполнения ГОЗ может повлечь серьезные
штрафные санкции и невозможность в будущем получать подобные заказы. В-
третьих, исполнение ГОЗ заказов должно проводиться обособленно от остальной
деятельности предприятия и правильно их выделять и на этапе планирования.
46
Совмещенное планирование продаж клиентам, дающим малый вклад в
общий объём выручки по отраслям промышленности - клиентов, дающих малый
вклад в выручку не целесообразно и даже невозможно планировать
индивидуально. Но при объединении клиентов для планирования всё же следует
не утерять возможность классифицировать данных клиентов. Такой
классификацией может быть классификация по отраслям и регионам. Данные
параметры, в сочетании с сведениями о публикуемой статистике и перечням
юридических лиц по регионам позволяют находить потенциальных клиентов,
работа с которыми ещё не ведется. В данной работе в качестве такой
классификации клиентов используется классификация по отраслям.
Укрупнение до номенклатурных групп при планировании обеспечивает
упрощенное создание модельного примера, упрощенное управление
справочниками, а значит и более оперативное планирование. В качестве
номенклатурных групп планирования используюется счетание наименования
марок и видов профилей мелаллопроката, составленное в соответствии с
ГОСТ’ами и ТУ на металлопродукцию из прецмзионных сплавов.
Модификацию планов и настройки данной модификации также имеет
смысл осуществлять в укрупненных категориях, поскольку в любом случае
планирование будущего не может осуществляться с большой точностью в
деталях, а при объединении сходных элементов и планировании по группам всё
же можно добиться планирования приемлемого качества. В последствии, при
план-фактном анализе будет полезно иметь возможность вернуться к
используемой классификации и рассмотерть, что входило в ту или иную группу
при плнировании. Такая возможность нужна, поскольку классификация (в
частности отнесение клиентов к крупным или фоновым) может со временем
меняться. Исходя из этого состав экранных форм, который будет разработан
должен включать:
1. форму исходных данных с трансляцией на используемую при
планировании классификацию;
2. форму настроек сценариев планироавния по категориям ключевой
нормативно-справочной информации;
47
3. форму пересчета и отображения планов в формате приближенном к
требуемому смежными подразделениями;
4. формы отчетов по планам и план-фактного анализа в различных срезах
и детализации.
1.4.2. Обоснование проектных решений по программному обеспечению
В работе предполагается реализовать модуль в 1С системе, установленной
на предприятии. Для его использования достаточно будет использовать
программное обеспечение, рекомендуемое фирмой 1С: Сервер 1С предприятия,
установленный на базе Windows Server 2012, СУБД MS SQL Server 2014. На
клиентских машинах – использовать Windows 7 и установленный клиент 1С
Предприятие. Либо можно предложить альтернативный вариант с
использованием ОС семейства Линукс (можно рекомендовать Ubuntu Linux 18.04,
как наиболее распространенную и актуальную) как на клиентском компьютере,
так и на сервере и СУБД PostgreSQL не ниже 9.1.2.
Реализовывать решение целесообразно в системе 1С:УПП, в которой
работают подразделения продаж и которая ранее была значительно доработана в
части планирования продаж. Реализация решений в 1С:УПП осуществляется с
использованием встроенного языка программирования я языка запросов в
конфигураторе 1С.
1.4.3. Обоснование проектных решений по техническому обеспечению
Поскольку в работе используется уже установленное в компании
программное обеспечение, работающее на базе серверов 1С под управлением
операционной системы Windows Server 2012 в качестве сервера СУБД
используется кластер MS SQL Server 2014, то и в техническом отношении система
не требует изменений. Сетевой структуры, используемой на предприятии с
пропускной способностью 1Гбит/сек также достаточно для работы доработанной
системы.
48
Пользователям достаточно иметь ПК с операционной системой семейства
Windows не ниже Windows 7, процессор не ниже intel core i3 c тактовой частотой
3.2 ГГц и выше, жесткий диск SATA не менее 250 Гб, не менее 5 ГБ свобобного
места. [18]. Сетевая карта, поддерживающая скорость 100 Мбит/c. Компьютер
должен находиться в одной сети с сервером и иметь доступ по сети в 100 Мбит/c.
Сервер 1С Предприятия Intel Xeon серии 5000 и выше, не менее 8 ГБ оперативной
памяти, SAS 500 ГБ, не менее 30 Гб свободного места; RAID-Массив.
49
ГЛАВА 2. ПРОЕКТНАЯ ЧАСТЬ
2.1. Разработка проекта автоматизации
2.1.1. Этапы жизненного цикла проекта автоматизации
В данной работе рассматриваются две отдельных задачи: задача
автоматизации планирования продаж и задача применения планов продаж для
планирования производства и закупок и составления бюджетов. Масштабы этих
задач кардинально отличаются. Для задачи планирования продаж в
информационной системе компании ЗАО «НПО Союзнихром» существует
значительная часть первичной информации, требующейся для осуществления
планирования у этой системы мало число пользователей, но при этом отсутствуют
сами алгоритмы работы. В соответствии со стандартами ГОСТ Р ИСО/МЭК
12207-2010 [19] и 15288-2005 [20] доработки деятельность лучше всего
соответствует пошаговой инкрементной разработке с этапами, представленными
в Таблице 7.
Таблица 7. Этапы жизненного цикла автоматизации
планирования продаж
Этап
Цель
1. Замысел системы
Определить потребности и заинтересованные
стороны, определить основные необходимые
возможности.
2. Проектирование системы
Разработать и продемонстрировать прототип,
получить подтверждение целесообразности и
замечания.
3. Разработка системы
Реализовать и отладить модуль в
программном коде основной информационной
системы.
4. Тестирование и отладка
Циклическая демонстрация пользователям и
устранение замечаний до начала
эксплуатации на примере одного
подразделения.
5. Применение и поддержка
системы
Закрепление использования системы в
регулярной деятельности компании начиная с
пилотного
6. Замена системы на более
современную, прекращение
использования
Замена решения на более современное,
соответствующее актуальным потребностям
предпрятия решение в будущем
50
Проработка вопросов взаимосвязи планов и бюджетирования представляет
собой значительно более сложную задачу, в которой должно быть задействовано
значительно больше подразделений и с которой работать будет значительно
большее число пользователей. В связи с этим, для данной работы лучше подходит
каскадный подход ведения проектов с последовательным выполнением работ,
начиная от определения требований и составления концепции проекта.
Жизненный цикл такого проекта включает в себя этапы, представленные в
Таблице 8, составленные в соответствии с ГОСТ 34.601-90 [21]. Краткая схема
жизненного цикла в соответствии с каскадной моделью приведена на рисунке 18.
Таблица 8. Этапы жизненного цикла автоматизации процессов
планирования и бюджетирования
Этап
Цель
1. Предпроектное
обследование и фиксация
концепции
Определить и зафиксировать основные
применяемые в компании шаблоны, форм,
справочники. Определить узкие места и области
неэффективного взаимодействия.
2. Проектирование
системы, разработка
технического задания и
эскизного проекта
Разработать плавила и принципы, по которым
должна функционировать система.
3. Реализация или подбор
готового решения,
тестирование
Получить требуемую систему (реализовать или
внедрить). Проверить, что необходимый
функционал присутствует и работает.
4. Первичное наполнение
данными
Подготовить систему к эксплуатации.
Отслеживать особенности, которые могут
привести к неуспеху проекта.
5. Разработка
документации, обучение,
ввод в действие
Подготовка пользователей к работе с системой.
6. Эксплуатация,
сопровождение
Обеспечить регулярное и бесперебойное
функционирование процессов компании с
использованием новой системы планирования и
бюджетирования.
51
Рисунок 18 - Этапы жизненного цикла проекта автоматизации
2.1.2. Ожидаемые риски на этапах жизненного цикла проекта
автоматизации
Далеко не каждый проект автоматизации заканчивается успехом. Связано
это с ошибками, которые могут быть допущены на разных этапах жизни проекта
автоматизации. Чем масштабнее проект, чем больше сроки его реализации, чем
меньше взаимодействует разработчик с будущими пользователями системы, тем
больше риск неуспеха проекта. Для задачи автоматизации процессов продаж
основной риск состоит в том, что систему могут оставить без внимания и не
пользоваться ею. Это может произойти при изменении требований об уровне
детализации планирования со стороны руководства компании, что маловероятно,
поскольку снижение требований ведёт к ухудшению возможностей
планирования. Если же такое произойдёт, то это будет означать потерю
управления над работой компании со стороны руководства. Разработанное
решение также может быть не использовано, если будет плохо соответствовать
естественным процессам и уже существующим практикам. Для предотвращения
этого во время разработки системы будет регулярно осуществляться контакт с
будущими пользователями системы. Таким образом риски неуспеха данной
задачи достаточно невелики. Но всё же возможен также риск неверной оценки
значимости задачи и неверной оценки сложности её исполнения без
автоматизации. Для исключения влияния этого риска для тестирования
52
разрабатываемой системы активно привлекаются будущие пользователи, от
которых также собираются сведения о текущей трудоемкости процесса.
Кроме указанных рисков, важно принимать меры против риска утечки
конфиденциальной информации. Для сокращения этого риска при
проектировании и разработке программного модуля планирования и отчетов, на
базе которых строится планирование продаж, сразу должны быть учтены
возможные доступы. В том числе, данные отчеты и данные не должны быть
вообще доступны сотрудникам уровня ниже руководителя отдела продаж, а
руководители продаж должны иметь доступ только к своим направлениям. Что
касается доступа к системе в целом, то на предприятии защита доступа
осуществляется политикой защиты паролем доступа в информационные системы.
Применительно к проекту автоматизации всей системы планирования и
бюджетирования, в связи с масштабом проекта такие риски достаточно велики.
Ошибки, допущенные на этапе предпроектной подготовки в выборе целей и
подходов, могут сделать пустой тратой ресурсов всю остальную работу по
проекту. Недостаточная проработка и пропуск важных деталей при
предпроектном обследовании может привести к значительным ошибкам в
планировании, излишне оптимистичным срокам.
Излишняя надежда на подрядчика по внедрению и малая вовлеченность
персонала может привести к тому, что слишком поздно будут выявлены
критичные ошибки. Наоборот, решение выполнить проект только силами
штатного персонала может привести к тому, что этот персонал окажется погребён
под текущими задачами и новыми важными, срочными, грандиозными задачами
и окажется неспособным выполнить проект в разумные сроки. Увеличение штата
персонала, задействованного в проекте, может решить проблему только в том
случае, если он задействован только под проект и должным образом управляется.
Также значительной проблемой может оказаться неготовность
нормативно-справочной информации, что является типичной ситуацией, когда
значительная часть работы отдана на откуп конкретным исполнителям и ведётся
вне какой-либо строгой системы. Для наполнения системы потребуется
совмещение компетенций в предметной области, специалисты по которой
имеются на предприятии, так и компетенций по отражению данных в
53
информационных системах, требования которых к вводимой информации
постоянно повышаются. Это может вызвать необходимость временного
расширения штата, что также должно быть заложено в проект на ранних стадиях
и учитываться при оценке окупаемости проекта.
Информационные системы разрабатываются для определенных целей,
соответственно которым прорабатывается их функционал и предполагаемый
поставщиком порядок работы с этим функционалом. На предприятии могут
существовать иные правила работы в этой или смежных областях, связанные с
историческим развитием предприятия и привычным укладом. Видно, что
внедрение системы и существующий уклад входят в конфликт, для устранения
которого необходима управленческая воля и готовность внедрить новый порядок
работы, без которого значительно возрастут затраты на проект и затянутся его
сроки.
На этапе внедрения в эксплуатацию может выявиться много ситуаций,
когда требуется оперативное вмешательство в ход проекта и, либо принятие
волевого решения, либо оперативная доработка. Зачастую выбор идёт именно
между этими подходами к устранению возникающих проблем. При этом важно
иметь оба указанных способа их устранения в арсенале группы, занимающейся
внедрением. Если же какой-либо из этих ресурсов отсутствует, то велика
вероятность не выполнить проект.
Но даже в случае, когда оба этих ресурса имеются, но не позволяют
справиться со слишком большим потоком проблем, может понадобиться
вернуться к прежнему порядку работы, устранить замечания и лишь затем
попробовать повторно внедрить систему. Соответственно, смелый переход на
новую систему со «сжиганием всех мостов» и отказом от возможности возврата
на прежнюю систему сам по себе сопряжен с большим риском.
На всех этапах проекта также имеется и играет большую роль риск
отсутствия поддержки со стороны руководства и риски смены подхода во время
проекта. Изменение взглядов руководства на целесообразность проекта или на то,
как должен идти проект, может перечеркнуть достигнутые результаты и заставить
отказаться от проекта или начать всё с начала. Отчасти (хотя и не полностью)
защитой проекта и принятых в проекте подходов и решений может быть
54
понимание источников окупаемости проекта и их связи с применяемым
подходом.
Все перечисленные риски, схема которых приведена на рисунке 19, ведут в
трём основным проблемам проектов: чрезмерным затратам на проект,
превышению запланированных сроков, не достижению запланированных
результатов.
Рисунок 19 - Основные риски проекта автоматизации
Поскольку продвижение по проекту автоматизации сопряжено с большим
числом рисков, и чем дольше и масштабнее проект, тем больше проблем
возникает в ходе проекта и сложнее добиться результата, то следует, насколько
возможно, сокращать промежуток времени от начала проекта до достижения
промежуточного ощутимого результата. Именно поэтому в данной работе
применительно к рассматриваемой теме, предложен краткий жизненный цикл
проекта, указанный в предыдущем параграфе и включающий в себя:
1) создание модельного примера;
2) воспроизведение в информационной системе;