Теоретическая статья на тему управления запросами на изменение. Автор в статье, к сожалению, ни как не ссылается на процессы управления изменениями, реализованные в стандартном решении управления изменениями системы Solution Manager. Хотя из того, что написано в статье видно, что процессы управления изменениями, как их видит автор, очень сильно пересекаются с процессами управления изменениями в системе Solution Manager. Последняя часть, в которой описана реализация управления запросами на изменение по средствам собственной базы данных, кажется очень оторванной от реальных продуктивных систем для которых такое решение будет неприемлимо, как с точки зрения ИТ поддержки так и с точки зрения бизнес пользователей.
Ещё одна заноза тем, кто считает инструменты типа Query исключительно консультантскими \"наборами для сверок\".
Не слишком хорошо знаком с процессом, который выполняется, но легкость выполнения (а query это действительно легко и интуитивно понятно) сложной задачи без АБАПа это всегда здорово
Главное преимущество данного подхода - идея документировать всё, но оценивать позже. Действительно, зачастую получается подводить фразы опрашиваемого под известные лекала (настроенный функционал системы, например)
Удивил пункт 5. Взаимное представление (как то больше пресейлу такая информация нужна а не консалтингу) и конечно всяческие оценки наподобие конфидециальности и детализации (не зря пункты выделены как необязательные).
Статья, меня как студента, вывела на новый уровень понимания практического старта проектов. Собрала воедино понятия риска при внедрении и распределение ответственности. очень хорошая компиляция теории и практики.
Использовании отдельной транзакции загрузки данных через LSMW очень удобно. Такое решение позволяет пользователю самостоятельно загружать данные, например проводки по заработной плате из другой системы. Кроме того, не нужно привлекать абаперов и системных администраторов, для того чтобы реализовать интерфейс передачи данных и настроить объекты полномочий. Это всё может сделать один специалист из группы поддержки.
Рассмотрены ключевые элементы мотивации для перехода. Мне кажется, что рекомендации статьи можно с успехом применять не только к SAP, но и к практически любому ИТ-проекту. Позволила пересмотреть структуру своего дипломного проекта.
Статья для меня открыла своеобразные ключевые моменты для определения проблем и этапов при переходе с системы на систему, можно сказать систему показателей. А также элементы оптимизации.
Полное и качественное описание метода. Для полноты картины не хватает только сравнительной таблички с другими методами, в которой можно было бы отразить плюсы/минусы и границы применимости.
Комментарий от
Кирилл Сатарин
| 15 июля 2010, 12:48