Методология внедрения от данных, а не от бизнес - модели

[Recoilme]

Идеи описывать лень, основной смысл в статье: http://akop.ru/personal/1235?PARENT_RUBR=akop_art_it

Основной смысл:

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

Собственно вопрос: "Использовал ли кто-ть такую методологию внедрения при внедрении Аксапты, или эта методология ложится только на "голые" приложения?"

Грубо говоря пришли к заказчику и не бегаем по экспертам и не описываем бизнес процессы, а запираемся в серверной с IT шниками и анализируем потоки информации, переносим их в систему, а потом уж накладываем на это необходимый функционал...????

Глупый наверно вопрос, но всё таки???

[blokva]

Вопрос поставлен некорректно:
"Данные" - это понятие "ЧТО"
А БП - это "КТО, КОГДА, ГДЕ и КАК" обрабатывает данные, т.е. "ЧТО"
Посему "Данные" - это составная часть БП и их нельзя отрывать друг от друга!

[Hamster]

Мои 5 коп:

Подход автора в случае Axapta не работает, т-к здесь уже зашиты (причем очень жестко) объекты и операции над ними.
Среда разработки позволяет вытворять что угодно но...... практически с 0!
Тот набор классов/объектов который уже есть использовать можно, но очень сложно.

Поэтому любая команда внедряльщиков рано или поздно делает нелегкий выбор :

1) Написать что-то самим, с 99% вероятностью несовместимости со стандарным функционалом

2) Натянуть заказчика на стандартный функционал (или наоборот...).
Оба - не резиновые, могут порваться

3) ОЧЕНЬ долго и нудно ковырять станд. код чтобы выяснить как прибить к Axapta маахонькую фичу, причем без гарантии что это вообще можно сделать без тотальной переделки системы.

[Recoilme]

Слышал (только слышал) что ораклоиды при внедрении используют нечто похожее. Называют его мудренным иностранным словом

типа приходят делают прототип 1 системы, загоняют пользователей, делают прототип 2 ... прототип n/ вешают бизнес логику.

Интересный подход но он вроде как исключает наличее в системе готовых бизнес процессов.... ?? А у них вроде что -то есть такое ... над СУБД... Мудренное...

И что то непохоже чтобы у них сроки были меньше...

[blokva]

Это не Ораклоиды - это называется "Экстремальное программирование" это совсем из другой оперы.
И ничего он не исключает!

[ppson]

методика внедрения Oracle подразумевает выбор сценариев БП, предлагаемых OEB.

[Recoilme]

Я бы назвал это "Экстремальное внедрение". Много общего с экстремальным программированием, но все таки немного разные вещи.
Экстремальное программирование может применяться при обычной методологии. Пару месяцев ля-ля с заказчиком, потом прототип, потом запуск. Потом здесь не так , это изменилось... А вот он говорил... Так Этого вообще нельзя слушать... Так ведь это же все меняет... Это надо сделать ещё вчера....

И вот тут то и начинается экстремальное программирование

А я спрашиваю не пробовал ли кто нибуть максимально "отчуждиться" от БП ещё/уже на начальном этапе???

И в понятие начальный этап вкладывать не "Описание БП", а настройку прототипа под существующую модель данных???

[Recoilme]

Цитата:

Изначально опубликовано ppson
методика внедрения Oracle подразумевает выбор сценариев БП, предлагаемых OEB.

О! Спасибо ppson

Слухи оказались сильно преувеличены....

[RAM]

Внедряем финансы на крупном предприятии (Логистика уже работает более менее).
БП формально не исследовали вообще... составили только модель данных и начали настраивать систему. Основные решаемые проблемы лежат в области ньюансов отражения данных (для внедренцев) и ньюансов функционала системы (для пользователей). В общем, стандартная проблема взаимного сближения .

Анализ процессов идет ad hoc и чисто утилитарно - только в той части, в которой это позволяет выбрать тот или иной функционал.

[Тимур]

imho, первичны процессы управления, а не данные.
Данных может быть очень много, однако управлять они не позволят.
В данном случае ИТ - это всего лишь инструмент для управления.
Если хотите построить автоматизированне хранилище данных - то метод великолепно подойдет, если хотите автоматизировать систему управления предприятием - то такой подход выльется лишь в расходы для клиента, даже не в затраты.

[Ned]

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

[RAM]

Я не стал бы делить процессы и данные на первичные и вторичные. Это как инструмент и обрабатываемый предмет - одно бессмысленно без другого.

Модель данных строится на основе принципов бухгалтерского баланса (в нашем случае). Баланс - это инструмент управления или нет?

Хранилище данных требует управления или нет? Совершенствуя управление хранилищем, мы вносим вклад в совершенствование управления предприятием?

Другое дело, если мы оптимизируем процессы бухгалтерии (управленческий консалтинг), то и порядок доступа к хранилищу данных изменится. Но подход к автоматизации работы с хранилищем останется тот же.

Это я просто к тому, что автоматизируется всегда работа с данными, а не процессы управления .

[StoneRoller]

Цитата:

Изначально опубликовано RAM
Я не стал бы делить процессы и данные на первичные и вторичные. Это как инструмент и обрабатываемый предмет - одно бессмысленно без другого.

Модель данных строится на основе принципов бухгалтерского баланса (в нашем случае). Баланс - это инструмент управления или нет?

Хранилище данных требует управления или нет? Совершенствуя управление хранилищем, мы вносим вклад в совершенствование управления предприятием?

Другое дело, если мы оптимизируем процессы бухгалтерии (управленческий консалтинг), то и порядок доступа к хранилищу данных изменится. Но подход к автоматизации работы с хранилищем останется тот же.

Это я просто к тому, что автоматизируется всегда работа с данными, а не процессы управления .

Софистика)) На мой взгляд управление процессами и управление данными вообще можно разорвать без дальнейших проблем. Потому как набор вторых всегда производная от первых.

[Тимур]

> Совершенствуя управление хранилищем, мы вносим вклад в совершенствование
> управления предприятием?

А это очень большой вопрос. Как не все расходы являются затратами, так не все совершенствования предролагают добавленную стоимость.
Вобщем то, можно сказать, что предлагаемый автором статьи подход можно сравнить с автоматизацией документооборота. То есть предлагается управлять потоком данных (фактически система класса "Машина"), в то время как процессы управления связаны напрямую с ресурсами (и их автоматизация - это система "Человек-Машина").

[Valery]

На мой взгляд, "запершись в кабинете с IT-шниками" можно реализовать только либо простые задачи, либо не сильно зависящие от специфики конкретного предприятия (например, бухгалтерия). В случае внедрения ERP-системы такой подход не прокатит.
Хоть стандартный функционал адаптируй, хоть заново пиши - с бизнес-процессами необходимо детально познакомиться.
Другое дело, что поскольку внедрениями занимаются в основном консалтинговые компании, наблюдается некоторый перекос в сторону бизнес-процессов. Чаще всего под лозунгом внедрения одновременно ведутся два проекта - консалтинговый (реинжиниринг бизнес-процессов) и собственно внедренческий. Причем консультанты утверждают (им это выгодно) что по-другому нельзя: "ну не будете же вы автоматизировать хаос...." Я с каждым проектом все больше убеждаюсь, что внедренческий и консалтинговый проект по сути своей слабо связаны. Для внедренческого результаты консалтинга практически не нужны. (Очень частая картина, наблюдавшаяся мной в разных консалтинговых компаниях: сперва полгода рисуются километры схем бизнес-процессов, а потом начинается внедрение, и о схемах никто не вспоминет, они пылятся на полках и никак не используются.)
Да, обследовать бизнес-процессы нужно, но затем, по моему мнению, надо переходить к той самой "разработке от данных". Просто не надо путать понятия. Под данными здесь понимается не то, что хранится в базе данных, а "базовые информационные структуры, описывающие корпоративную информацию (предметную область)". Именно сперва определить эти самые базовые информационные структуры, а затем на этой основе получать перечень информационных функций, которые должна выполнять система - вот это мейнстрим внедрения. А углубляться в бизнес-процессы: как там баба Нюра будет передавать накладную дяде Саше, то ли через тётю Свету, то ли сама - для внедрения не существенно.

[belugin]

Цитата:

"базовые информационные структуры, описывающие корпоративную информацию (предметную область)"

в ОО есть еще хорошее словосочетание "ключевые абстракции"

[Тимур]

Valery

> ...не сильно зависящие от специфики конкретного предприятия (например, бухгалтерия..."
Очень неудачный пример.
Очевидно Вы позабыли про учет НЗП и МПЗ... Они то очень сильно зависят от специфики производства.
Поглядите хотя бы как первичные документы от отрасли к отрасли отличаются!

Что же такое, по-вашему "базовые информационные структуры, описывающие корпоративную информацию (предметную область)"?

[Valery]

Да, согласен, неудачный пример. Вставил не подумав.
Про "базовые информационные структуры, описывающие корпоративную информацию (предметную область)" лучше где-нибудь почитать. Например классику ООП, классику методологии концептуального проектирования систем организационного управления и т.д.

[sergey_alekseev]

Всем добрый день!
Очень интересный постинг. Хочу провентилировать один вопрос.
Понятно, что конечным пользователям нужны именно данные, и правильность их представления ключевой момент при внедрении. Тогда возникает вопрос: "А данные каким образом появляются?".
Ведь не из словаря, беруться. И мне кажеться на этот вопрос отвечает описание информационных потоков предприятия, или документооборот (часто называют).
А все эти информационные потоки неотъемлемая часть бизнес процессов.
Получается, что если мы хотим получить корректные данные, нам необходимо изучить и их производство (Производство данных).
С чего начать - это уже дело вкуса.

[Тимур]

Валерий, не могли бы Вы дать ссылку.
Или все же пояснить. Несколько не моя сфера - программирование.