-Поиск по дневнику

Поиск сообщений в lj_ru_abap

 -Подписка по e-mail

 

 -Постоянные читатели

 -Статистика

Статистика LiveInternet.ru: показано количество хитов и посетителей
Создан: 07.12.2006
Записей: 39
Комментариев: 0
Написано: 0




ABAP как он есть... - LiveJournal.com


Добавить любой RSS - источник (включая журнал LiveJournal) в свою ленту друзей вы можете на странице синдикации.

Исходная информация - http://community.livejournal.com/ru_abap/.
Данный дневник сформирован из открытого RSS-источника по адресу http://ru-abap.livejournal.com/data/rss/??2e0a4e00, и дополняется в соответствии с дополнением данного источника. Он может не соответствовать содержимому оригинальной страницы. Трансляция создана автоматически по запросу читателей этой RSS ленты.
По всем вопросам о работе данного сервиса обращаться со страницы контактной информации.

[Обновить трансляцию]

Вакансия ABAP разработчика в Спб

Вторник, 02 Ноября 2010 г. 14:32 + в цитатник
Добрый день. Открылась вакансия ABAP разработчика в компании CIBER в Санкт-Петербурге.

Основные задачи:
1. Разработка программ и отчётов
2. Участие в проектах в качестве разработчика

Необходимые навыки и знания:
1. ABAP Workbench
2. ABAP OO
2. Вывод результатов в ALV-Grid, ALV-Tree, SALV, Write, MS Word, MS Excel, PDF, Smart-Form.
3. Желательно: IDOC's, Web Dynpro, Portal, WorkFlow.

Заработная плата от 40 т.р.
Резюме высылать по адресу: sergey.zhuravlev[at]ciber.com

https://ru-abap.livejournal.com/29508.html


Вакансия ABAP разработчика в Спб

Вторник, 02 Ноября 2010 г. 14:32 + в цитатник
Добрый день. Открылась вакансия ABAP разработчика в компании CIBER в Санкт-Петербурге.

Основные задачи:
1. Разработка программ и отчётов
2. Участие в проектах в качестве разработчика

Необходимые навыки и знания:
1. ABAP Workbench
2. ABAP OO
2. Вывод результатов в ALV-Grid, ALV-Tree, SALV, Write, MS Word, MS Excel, PDF, Smart-Form.
3. Желательно: IDOC's, Web Dynpro, Portal, WorkFlow.

Заработная плата от 40 т.р.
Резюме высылать по адресу: sergey.zhuravlev[at]ciber.com

https://ru-abap.livejournal.com/29508.html


Грабли внедрения ERP систем. Грабли пятые

Четверг, 21 Октября 2010 г. 20:00 + в цитатник

Помни почему "рухнул" проект "Вавилонская башня".

Книга

Грабли пятые

Предупреждение

"Одна из самых значительных причин недоразумений между командами внедрения и заинтересованными сторонами состоит в различном определении ключевой терминологии, что приводит к конфликтам в момент реализации. Даже члены одной и той же команды часто интерпретируют термины по-разному.

Из-за высокой вероятности двусмысленного толкования терминологии процесс разработки глоссария требует значительных усилий. Во время совместной работы над ним необходимо выявить и устранить различия в ожиданиях, результатом чего должен стать совместно сформированный глоссарий, применение которого сократит вероятность возникновения последующих недоразумений". (Люк Галоппен, Зигфрид Кемс "Управление организационными изменениями при внедрении SAP", Издательство ООО "Эксперт РП", 2009 )

Превратности метода

Люк Галоппен, Зигфрид Кемс приводят в качестве примера неверного толкования термин "change management". Этот термин, который означает "управление изменениями самой компании", часто понимают с подменой понятия по следующим вариантам:

· "управление имениями в рамках проекта" (внедрения ERP системы);

· "управление изменениями в программном обеспечении" (в рамках проекта внедрения ERP системы);

· "изменение команды менеджеров".

Тайваньский казус

Тема управления изменениями (change management) была отвергнута руководством тайваньской компании как неподлежащая обсуждению, потому что понималась им как "смена руководства".

Написано для www.sapland.ru

https://ru-abap.livejournal.com/29420.html


Грабли внедрения ERP систем. Грабли четвертые

Понедельник, 04 Октября 2010 г. 11:39 + в цитатник

Не наливайте нового вина в старые меха.
Книга

Грабли четвертые

Предупреждение

Типичной ошибкой является реализация отчетов, используемых в настоящее время (до внедрения), в ERP системе в том же формате и с прежней информацией.

Причиной этого является:

· и рядовые исполнители и топ-менеджеры предполагают даже после внедрения ERP системы работать "по старому";

· при продаже системы Заказчику обещано "отчетность на любой вкус".

В результате все тратят усилия на удовлетворение требований "вчерашнего дня".

Следует ЛЮБОЙ ценой уйти от определения будущей системы отчетности с позиции сложившийся практики.

Превратности метода

Отчет "Складские запасы на заданную дату", который требуют практически все заказчики, является типичным отчетом "вчерашнего дня". Требование реализации данного отчета в ERP системе является симптомом того, что сотрудники заказчика не понимают организации будущих бизнес-процессов.

Для решения проблемы "вчерашней отчетности" Люк Галоппен и Зигфрид Кемс рекомендуют:

· привлекать к совещаниям по проекту руководства среднего звена;

· вести разработку отчетов "с нуля";

· разрабатывать отчеты с позиции будущих бизнес-преимуществ и будущих способ работы.

Казус компании Z

Казус "отчетности вчерашнего дня" произошел при внедрении ERP системы в производственной компании Z.

Не обращая внимания на доводы внешних консультантов руководство приняло решение о разработке большого количества отчетов "вчерашнего дня". В результате бюджет проекта был увеличен на 10%.

Через полгода эксплуатации выяснилось, что 40% отчетов "вчерашнего дня" не использовались ни разу, а 50% использовалось только первые два месяца эксплуатации системы.

Написано для www.sapland.ru

https://ru-abap.livejournal.com/28998.html


Грабли внедрения ERP систем. Грабли третьи

Понедельник, 20 Сентября 2010 г. 19:47 + в цитатник

Менять мир начинай с себя.

Совет


Предупреждение

Классическим началом проекта внедрения ERP системы (предпроект) является анализ (моделирование) текущих бизнес-процессов, так называемое построение модели as-is.

При этом:

1) Основное внимание уделяется проблемам важным в настоящий в момент. В результате получаются ложные опорные точки, так как эти проблемы, в случае изменения бизнес-процессов в соответствии с best practices, чаще всего теряют актуальность.

2) В отсутствие модели to be построение модели бизнес-процессов as-is осуществляется без целевого ориентира, в результате создаваемый документ описывает аргументы, по которым не стоит вносить изменения в существующие бизнес-процессы.

В результате построения модели to be и гэп-анализа с ранее созданной моделью as-is формируется большой список "расхождений". И начинается долгое обсуждение "что и как менять".

И практически всегда, когда ERP система не поддерживает тот или иной бизнес-процесс, принимается решение об изменении системы, хотя чаще всего должен быть пересмотрен бизнес-процесс.

Превратности метода

В начале проекта многие топ-менеджеры уверяют консалтинговые фирмы, что не станут требовать изменения ERP системы, но в итоге всё равно это делают. Всё дело в организации проекта внедрения.

Изменение стандартной ERP системы должны быть приняты только топ-менеджерами.

Предложение об изменении ERP системы является сигналом для топ-менеджеров о необходимости привлечения экспертов, имеющих достаточное количество знаний, умений и опыта, чтобы определить, возможно ли решение проблемы стандартными средствами и решениями ERP системы

Казус компании Y

В начале проекта генеральный директор имел твердое намерение внедрить стандарт ERP системы, максимально применяя best practices, о чем неоднократно заявлял.

В результате гэп-анализа была выявлена необходимость существенного изменения в организации бизнес-процессов и порядка их учета. Генеральный директор не имел соответствующей компетенции в бухгалтерском учете, и полномочия по принятию решения о необходимых изменениях было делегировано финансовому директору.

Неудивительно, что было принято решение о "натягивании" ERP на существующие бизнес-процессы и методы учета.

Впоследствии топ-менеджмент компании с удивлением узнал, что в результате ранее принятых решений в модифицированной ERP системе невозможно осуществить MRPII планирование, а выполнение простых операций требует от персонала больших усилий.

https://ru-abap.livejournal.com/27975.html


Грабли вторые

Вторник, 14 Сентября 2010 г. 18:12 + в цитатник

Семь раз отмерь – один раз модифицируй.

Народная мудрость

Предупреждение

"Мы часто видим, как организации, внедряющие SAP, вносят большое количество изменений в стандартный пакет, чтобы он соответствовал специфическим потребностям организации. Чтобы сделать внедрение SAP успешным, необходимо интегрировать систему в организацию. Организация должна принять систему, а система должна поддерживать новые внедренные методы работы.

SAP считается готовым к использованию продуктом, поддерживающим лучшие методы организации работы (Best Practices). Система SAP разработана для поддержания таких методов, и эта поддержка функционирует максимально эффективно в том случае, если в систему не вносится слишком много изменений. Вы можете конфигурировать систему SAP, чтобы настроить её с учетом специфики внедряющей её организации, однако нельзя ставить цель перепроектирования системы. Как только этот основополагающий факт будет осмыслен, сразу станет понятно и то, что именно в организации должно быть настроено для соответствия системным методам работы.

Искусство успешного внедрения заключается в поиске необходимого баланса между интеграцией SAP в организацию и интеграция организации в SAP."

(Люк Галоппен, Зигфрид Кемс "Управление организационными изменениями при внедрении SAP", Издательство ООО "Эксперт РП", 2009 )

Превратности метода

Во всех проектах внедрения ERP систем, в которых я участвовал, при определении объема (scope) проекта ключевой проблемой обсуждения являлась проблема устранения несоответствия между возможностью ERP системы и текущими бизнес процессами. И, как правило, принималось волевое решение о "натягивании" ERP системы на бизнес-процессы за счет её модификации и "уродливых" настроек.

Собственникам и топ-менеджерам казалось, что существующие бизнес-процессы оптимальны, а их изменение нецелесообразно. Консультант же не мог им противостоять, так как боялся потерять клиента.

В случаях, когда принималось решение об изменении бизнес-процессов "под best practice от ERP", проект всегда наступал на грабли №3, о которых я расскажу в следующей колонке.

Типичные результаты подхода "натягивания системы на существующие бизнес-процессы" :

· Расширение функциональности внедренной системы либо слишком затратно, либо вообще невозможно;

· Переход на новую версию внедренной системы потребует чрезмерных затрат, сопровождать же систему могут только консультанты её внедрявшие;

· Внедрение ERP системы не принесло существенных бизнес-преимуществ.

Казус холдинга Х

При внедрении ERP системы в одном из известных холдингов произошел казус. Через полгода после доклада об успешном внедрении ERP системы холдинг был продан и новым руководителем был назначен иностранный менеджер. Этот менеджер потребовал осуществления планирования в ERP системе. Оказалось, что после "такого" внедрения это просто невозможно.

Какой же выход нашел ИТ-директор?! Он посадил двух сотрудников, которые набивали в ERP систему план, составленный вручную!

Создано для www.sapland.ru

https://ru-abap.livejournal.com/26757.html



Поиск сообщений в lj_ru_abap
Страницы: [2] 1 Календарь