52
3. Использование нескольких программных продуктов, не
интегрированных между собой для реализации процесса;
4. Большой и неравномерный поток заключения договоров;
5. Отсутствие заключения договоров в электронной форме;
6. Частые командировки уполномоченных подписантов;
7. Сложность используемых информационных систем;
8. Частая географическая отдаленность контрагентов.
Таблица 3
Матрица SWOT анализа
Возможности
Угрозы
Сильные
стороны
1. Высокий опыт и уровень квалификации
исполнителей
2. Высокий уровень материально-
технического обеспечения процесса
3. Полная и качественная регламентация
процесса
4. Высокий уровень автоматизации процесса
1. Возможность коррупционных и
мошеннических действий со
стороны
исполнителей
2. Возможность длительного
времени выполнения процесса
Слабые
стороны
1. Слабая гибкость процесса (большое время
для внесения изменений в процесс)
2. Большое количество участников процесса
3. Использование нескольких программных
продуктов, не интегрированных между собой
для реализации процесса
4. Большой и неравномерный поток
заключения договоров
5. Отсутствие заключения договоров в
электронной форме
6. Частые командировки уполномоченных
подписантов
7. Сложность используемых информационных
систем
8. Частая географическая отдаленность
контрагентов
1. Возможность получения
убытков из-за ненадлежащего
выполнения своих обязанностей
исполнителями
2. Возможность несоблюдение
законодательства РФ
3. Возможность сбоев в
информационных системах
При проведении SWOT – анализа приоритетное внимание необходимо
обращать на слабые стороны процесса, которые одновременно являются
возможностями, это следующие слабые стороны:
1. Большой и неравномерный поток заключения договоров;
2. Отсутствие заключения договоров в электронной форме;
3. Частые командировки уполномоченных подписантов;
53
4. Частая географическая отдаленность контрагентов.
Первая слабая сторона процесса связана с тем, что некоторые отрезки
времени заключается большой объем договоров, в данные периоды времени
ощущается резкая нехватка кураторов договоров, а также должностных лиц
от структурных подразделений, участвующих в согласовании договора, по
этой причине время реализации бизнес-процесса может затягиваться
довольно сильно.
Для реализации 1 возможности, необходимо найти методику, благодаря
которой можно точно оценивать количество договоров, которое будет
заключаться в период, к примеру, за 1 месяц и в соответствии с полученными
данными регулировать количество людских ресурсов, участвующих в данном
процесса. Это позволит в пиковые периоды заключать необходимое
количество договоров с нормальной длительностью процесса и должным
качеством.
Слабые стороны – возможности 2, 3 и 4 связаны между собой. Если
реализовать возможность 2, то и не будет отрицательного влития
возможности 3,4. Если договоры будут заключаться в электронной форме, то
не важно где находится уполномоченный подписант и где находится
контрагент, договор может быть подписан в любом месте в электронной
форме с применением ЭЦП.
Это позволит в большинстве ситуаций значительно снизить время
реализации процесса, так как нет необходимости в физическом перемещении
договора на бумажные носители. Для того чтобы воспользоваться данной
возможностью как можно быстрей, можно внедрить тестовый порядок
заключения договора в электронной форме, данный порядок будет
реализовываться в тех случаях, когда контрагент является надежным, когда
имеется большая срочность договора и нет возможности его быстро
подписать в бумажном виде обеими сторонами (удаленность контрагента,
отсутствие на рабочем месте уполномоченного подписанта).
54
Подписание договора в электронной форме не противоречит
законодательству РФ, но для подписания необходимо наличие ЭЦП
должного вида у обоих сторон, а также включение в текст договора оговорки,
о возможности подписание документа в электронной форме. При внедрении
временного порядка подписания договоров в электронной форме,
предполагается наличие ЭЦП у всех уполномоченных подписантов.
На основании результатов SWOT – анализа построим модель процесса
«Как будет» администрирования договоров. Необходимо заметить, что
процесс «Как будет», менее детализировать, чем процесс «Как есть». Это
объясняется тем, что некоторые группы функций нового процесса
объединены на схеме в одной функции подпроцесс, где выделены
следующие подпроцессы:
˗ процесс пред согласования договора;
˗ процесс работы участника на ЭТП;
˗ процесс выбора победителя;
˗ процесс окончательного согласования.
Процессы пред согласования договора и окончательного согласования
не изменятся, а останутся такими же, как есть на данной момент в бизнес-
процессе «Как есть» администрирования договоров.
Схема реализации данных под процессами останется прежней,
предполагается только внедрения системы планирования ресурсов при их
реализации. Процесс работы участника на ЭТП не детализирован, так как
участники данного подпроцесса являются внешними по отношению к
компании, то есть это контрагенты, участвующие в конкурсе на право
заключения договора. Процесс выбора победителя не детализирован по той
причине, что данный под процесс реализуют сотрудники компании, он
регламентирован и описан в ЛНД и не подлежит изменению. Нужно
заметить, что даже после внедрения бизнес-процесса «Как будет»
администрирования договоров, не все договора будут заключаться в
электронной форме.
55
Это возникнет по следующим объективным причинам:
1. Заключение договоров с физическими лицами
2. Заключения договоров с государственными учреждениями, у
которых нет возможности заключить электронный договор
3. Заключение договора с контрагентами, у которых нет возможности
заключить электронный договор, особенно в ситуации, когда данный
контрагент является безальтернативным для компании
4. Заключение других договоров и контактов где использование
электронного договора невозможно или необоснованно.
На основании данных причин бизнес-процесс «Как будет»
администрирования договоров будет начинаться с проверки возможности
использования электронной форме договора, представим схему проверки
данной возможности на рисунке 8. Таким образов при заключении договора,
когда есть объективные причины, не дающие возможность заключения
договора в электронной форме, процесс администрирования договоров будет
реализован по старому сценарию.
Рис. 8. Проверка возможности использования электронной формы договора
56
На анализе статистики заключения договоров компании в разрезе
контрагентом, можно предположить, что порядка 80 процентов договором
можно заключать в электронной форме ближайшей перспективе. Остальные
20 процентов будут приходиться преимущественно на государственные
учреждения. Хочется надеяться, что государственные учреждения в видимой
перспективе тоже будут использовать электронный договор в своей
практике.
Выводы к главе 2:
ООО «ТЦМ» — ведущий российский разработчик газотурбинных
двигателей для военной и гражданской авиации. Включает в себя
конструкторское бюро, современную производственную и
экспериментальную базы.
Объектом исследования в данной работе является управление контроля
контрактования и соблюдения процедур компании ООО «ТЦМ» (далее
УККиСП). Основным бизнес-процессом данного структурного
подразделения, является процесс «Администрирования договор».
Для анализа выбераны следующие показатели:
˗ длительность процесса (время реализации);
˗ количество нарушений в области контрактования;
˗ частота использования стандартной формы договора;
˗ частота использования проекта договора компании.
В данной работе выделено 5 главных методов совершенствования
инновационных бизнес-процессов предприятия:
1. Использование метода быстрого анализа решения (FAST);
2. Применение метода бенчмаркинга;
3. Осуществление перепроектирования бизнес-процессов;
4. Применение метода инжиниринга;
5. Применение метода реинжиниринга.
57
Для повышения инновативности компании ООО «ТЦМ», было принято
решение использовать метод реинжиниринга бизнес-процессов. Ещё раз
дадим характеристику данному методу.
58
ГЛАВА 3. ЭТАПЫ ВНЕДРЕНИЯ РАЗРАБОТАННОГО
БИЗНЕС-ПРОЦЕССА С ИСПОЛЬЗОВАНИЕМ
ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ
3.1 Структура проекта внедрения
В ООО «ТЦМ» для обеспечения бизнес-процессов используется
корпоративная система управления КИС SAP R/3. Данная система является
единым хранилищем данных, содержащих всю корпоративную бизнес
информацию, и обеспечивает одновременный доступ к ней любого
необходимого числа сотрудников Компании, наделенных определенными
полномочиями. КИС SAP R/3 позволяет повысить эффективность
производственной деятельности Компании и сократить внутренние
информационные потоки.
Подсистемы SAP:
˗ управление договорами;
˗ управление расчетами с дебиторами и кредиторами;
˗ управление Финансовым бюджетом;
˗ управление финансовыми потоками;
˗ нормативное обеспечение бизнеса;
˗ управление закупками;
˗ управление материальными потоками;
˗ бухгалтерский учет и отчетность;
˗ управление результатом хозяйственной деятельности;
˗ бизнес-планирование;
˗ ведение штатной структуры организации, кадровый учет и кадровый
документооборот.
Система SAP R/3 является набором интегрированных между собой
приложений, данные приложения написаны на кросплатформенном языке.
Данный язык занимает основополагающее место в ПО связного уровня, что
59
позволяет сделать SAP R/3 аппаратно-независимой, кроссплатформенной и
работающей с различными СУБД (рисунок 9).
Рис. 9. Многоуровневая структура системы R/3
В связное программное обеспечение SAP R/3 базовой версии входят
следующие архитектурные компоненты:
˗ GUI (графический интерфейс пользователя);
˗ средства разработки АВАР/4 Development Workbench;
˗ исполнительная система АВАР/4;
˗ интерфейс базы данных;
˗ система электронной почты;
˗ средства поддержки многопользовательского режима;
˗ система автоматизации совместной обработки данных;
˗ средства интеграции персональных компьютеров с программным
обеспечением;
˗ средства фоновой обработки заданий;
˗ средства администрирования системы;
˗ система спулинга;
˗ интерфейсы связи с внешними системами.
Система R/3, разработанная на базе трехуровневой архитектуры,
предназначена для реализации распределенных вычислений в среде
клиент/сервер. R/3 содержит три логических уровня: ˗ уровень базы данных,
60
на котором осуществляется хранение и поиск данных бизнес-приложения ˗
уровень приложения, на котором реализована логика исполнения ˗ уровень
представления информации с использованием GUI ˗ каждая из этих служб
может быть распределена и исполняться на различных аппаратных
устройствах (рис. 10).
Рис. 10. Трехуровневая архитектура системы R/3
Архитектура системы R/3 позволяет объединять два или три уровня в
одном компьютере «физически» (рис. 11) — если не требуется более высокая
степень распределения функций.
Рис. 11. Масштабирование системы R/3
Средства разработки АВАР/4 Development Workbench интегрированы в
R/3 Basis, что дает возможность разрабатывать приложения, отвечающие
стандартным требованиям к бизнес-приложениям SAP. В частности,
61
программы, созданные с помощью Development Workbench, поддерживают
различные вычислительные среды, т.е. являются переносимыми. Схема
системы SAP R/3 представлена на рисунке 12.
В архитектуре клиент/сервер реализованы разные модели
распределения функций, поэтому система обеспечивает несколько вариантов
масштабирования R/3 — от самых малых систем (одноуровневой для
небольшого числа пользователей) до крупномасштабных вычислительных
сред (трехуровневых систем для многих тысяч пользователей).
Службы системы R/3 могут быть распределены в гетерогенных
вычислительных средах, поддерживающих различные операционные
системы и программы представления данных. Архитектура системы R/3
позволяет минимизировать сетевой трафик обмена данными с помощью
буферизации и сжатия информации.
Это очень важно для систем клиент/сервер, где требуется быстрая и
надежная передача данных. Механизм диспетчеризации системы R/3
поддерживает многопользовательский режим работы, управляя сессиями
всех пользователей.
Специальный метод оптимизации загрузки гарантирует равномерную
загрузку всех серверов приложений, что позволяет избежать дисбаланса в
использовании ресурсов в системе.
Рис. 12. Строение SAP