Внедрение SAP R/3: Руководство для менеджеров и инженеров - Вивек Кале
Шрифт:
Интервал:
Закладка:
Что необходимо учитывать при оценке ERP-системы
В этом разделе описываются различные ситуации, имеющие значение при оценке той или иной ERP-системы.
Функциональность и возможности ERP-продуктаПри оценке поставляемых программных ERP-продуктов могут применяться те же критерии, что и при оценке качеств компании-поставщика. Критерии оценки продукта также включают в себя вопросы, представленные в таблице 2.2.
В отличие от традиционных компьютерных систем, которые при обработке операций предприятия ориентируются на данные, системы в масштабе всего предприятия делают акцент на процессы. Поэтому необходимо убедиться в том, что ERP-система способна конфигурировать, поддерживать и выполнять рабочие процессы в организации.
Поддержка стандартных процессов и лучших методов организации производственных работ
Компании с несколькими подразделениями и/или расположенные в нескольких значительно удаленных друг от друга офисах, развиваются по-разному; такое развитие может принимать индивидуальный характер и не вписываться в общий шаблон, охватывающий всю организацию. Система ERP обязательно должна иметь полную функциональность для интеграции этих укоренившихся отличий в операциях самостоятельных подразделений компании и предоставить лучшие в своем роде, готовые к использованию процессы, которые объединили бы различающиеся способы проведения деловых операций или процессов.
Стандартизация процессов, как правило, дает неоценимые преимущества для содержания системы, а также при проведении будущих модернизаций, обучении персонала, сопровождения и администрировании системы приложений ERP.
Система должна поддерживать настройку процессовТакая функциональность обычно противоречит общей тенденции к стандартизации и внедрению общепринятых процессов. Но то, что выживание и успех компании зависят от ее способности поддерживать собственную индивидуальность, что ее продукция должна отличаться от продукции и услуг конкурентов, уже стало избитой, банальной фразой. Для укрепления своего профессионализма, для полного использования своих преимуществ компания не должна отказываться от тех процессов, которые составляют ее индивидуальность. Такие, коренным образом отличающиеся процессы
Следовательно, в дополнение к лучшим в своем роде процессам, ERP-система должна предоставлять базовую структуру и стратегию для интеграции специфических для данной компании (или даже для подразделения) процессов и функций. Как предлагается в главе 10 «Инициация проекта SAP», компания Должна рационализировать, стандартизовать, и, насколько возможно, использовать настройки процессов, доступные в системе SAP.
Необходимость в настройках может возникнуть по следующим причинам:
• Законы и правила, принятые в конкретной стране
• Законы и правила, принятые в конкретном регионе
• Требования к ведению дел, принятые в конкретной стране
• Стратегия и тактика бизнеса, принятая в конкретной компании
• Особенности ведения дел и операционные требования в разных подразделениях и разных офисах компании.
Поддержка исключительных процессов
Эти процессы также известны как особые ситуации или нестандартные процессы. Сценарии таких процессов в рамках организации могут возникнуть в результате особых или непредвиденных обстоятельств, возникающих в разные моменты времени. Система может воспринять такой сценарий как ошибку, или выполнить его после того, как пользователь идентифицирует этот процесс как исключительный. Например, почти каждая организация иногда вынуждена сделать исключение из правил, когда она выбирает поставщиков, или делает предложение потенциальному покупателю, поставляет продукцию задолжавшему, но верному клиенту, осуществляет просроченный платеж или частичный платеж по неподтвержденному счету-фактуре и т. д.
Исключительные процессы являются одним из главных объектов настроек в системе. Впрочем, как уже обсуждалось выше, решения по внесению изменений должны приниматься только после оценки возникающих в результате настройки сложностей по использованию, обучению, поддержанию данных и подчиненных процессов.
Надежность поставщика системы
Организация может остановить свой выбор на той или иной ERP-системе, основываясь на надежности программного продукта: этот вопрос рассматривается в следующем разделе. Однако, надежность компании-поставщика также имеет большое значение, потому что от нее зависит дальнейшая модернизация и развитие программных продуктов, что особенно важно в контексте стремительных перемен в технологии и требованиях рынка. Вопросы, касающиеся надежности компании-поставщика, приведены в таблице 2.1.
Архитектура и технология ERPСистема ERP должна внедряться с использованием новейших технологий, архитектуры и методологии. Поскольку технология продолжает динамично развиваться, особое значение приобретает архитектура системы, так как именно она позволяет модернизировать отдельные модули таких монолитных систем, как SAP, без остановки работы всей системы.
Трехслойная архитектура
Клиент-серверные вычисления дают огромные преимущества в отношении распределения нагрузки на систему, масштабирования и гибкости, необходимой для развития.
Трехслойная архитектура системы состоит из уровня презентаций, уровня приложений и уровня баз данных — и это оптимальная реализация режима клиент-сервер. Ниже приведены характеристики каждого уровня:
• Уровень презентаций управляет диалогом между конечным пользователем и каким-либо приложением, программой (см. следующий раздел «Графический интерфейс пользователя»).
• Уровень приложений осуществляет трансформацию данных, в чем, по сути, и заключается предназначение приложений.
• Уровень баз данных осуществляет хранение, обновление и предоставление данных с помощью программ, расположенных на уровне приложений. См. раздел «Принцип клиент-сервер» в главе 4.
Графический интерфейс пользователя
Возможно, покажется странным, что я рассуждаю о важности GUI, но ведь еще несколько лет назад стандартная функциональность такого интерфейса была недоступна, особенно для систем типа ERP, в которых акцент делался на гибкость, всеобъемлющую функциональность и возможность внесения изменений. Графический интерфейс пользователя позволяет системе приблизиться к пользователю, предоставив ему следующие возможности:
• Структурирование и размещение меню
• Облегчение движения курсора по экрану
• Навигация между разными экранами
• Предоставление справки (помощи) в контексте конкретной ситуации
• Вывод на экран сообщений о сбоях и ошибках.
Существует пять вариантов трехслойной архитектуры в сочетании с режимом «Клиент-Сервер»:
• Распределенное управление данными: данные разбиваются на две части — одна часть на терминале клиента, другая — на сервере.
• Удаленное управление данными: интерфейс пользователя и логические операции осуществляются приложениями на терминале пользователя, в то время как база данных находится на сервере. Это традиционная модель отношений «Клиент-Сервер».
• Дистрибуция внутреннего устройства программ: логические операции осуществляются приложениями и на терминале пользователя, и на сервере. Такой вариант больше всего подходит для распределенных предприятий.
• Удаленное представление: само приложение и база данных находятся на сервере, в то время как программы презентации работают на терминале пользователя.
• Распределенное представление: операции, связанные с представлением, осуществляются приложениями и на терминале пользователя, и на сервере; система управления представлением работает на терминале пользователя, а сервер программ представления распределен между сервером и клиентом.
Рис. 2.1. Типы архитектуры клиент-сервер.
На рис. 2.1 показано пять основных вариантов трехслойной архитектуры в сочетании с режимом «Клиент-Сервер». О слое GUI подробно рассказано в разделе «Архитектура SAP» главы 4. Системе SAP ближе последние два варианта.
С наступлением эры Интернета, необходимость в отдельном, независимом GUI-интерфейсе стала еще более очевидной и насущной.
Открытые системные интерфейсы и прикладные программные интерфейсы
Последние десять лет разработок в области информационных технологий показали важность открытости систем; это подразумевает, что системы, протоколы и интерфейсы не должны быть собственностью других разработчиков. Концепцию ERP-системы легко понять, но очень трудно реализовать. Разработка такого монолитного продукта за короткое время просто немыслима. Следовательно, интерфейсы и архитектура ERP-системы должны предусматривать возможность постепенного развития различных компонентов ERP-системы без негативных последствий для ее интегрированной функциональности.