АОТ для бизнес аналитиков

[sukhanchik]

Цитата:

Сообщение от coolibin

Мы не будем нанимать людей, нафига нам всякие консультанты и аналитики, пусть нам сама Аксапта выполнит в нашем проекте роль и системного и бизнес аналитика и разработчика и напишет сама про себя документацию.

Грамотная мысль! Кстати - очень многие руководители считают, что дешевле что-то напрограммировать, нежели брать человека.
А по факту получается - что для автоматизации чего-то - сначала нужен ручной труд.

[AlGol]

Цитата:

Сообщение от sukhanchik

А по факту получается - что для автоматизации чего-то - сначала нужен ручной труд.

Поддерживаю - этот ручной труд простонародно "автоматизацией" и называется. Т.е. болтики и винтики надо вкрутить руками в определенное место чтобы машина сама ездить начала.

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

Но во-первых, это все придется описать именно руками, потому как никто, кроме аналитика не скажет что значит с точки зрения бизнес логики сложение двух переменных и сравнение результата с третьей. Т.е. по коду придется лазить очень усердно и с АОТ придется поработать очень плотно.
Во-вторых, для дальнейшего поддержания порядка в этом хозяйстве придется внедрить драконовские правила разработки. И оформление разработки внутри системы будет сравнимо с временем собственно кодирования. А этого вроде как и надо избежать.

Но основная засада в том, что при изменении одного из параметров системы этот алгоритм может заработать совсем не так как вам показалось сначала. А при попытке учесть все ньюансы его работы, описание, скорее всего превратиться в такую кашу, что уж лучше код прочитать...

Когда я начинал работать с Аксаптой, в моем ближайшем окружении было достаточно попыток описать ее логику с помощью диаграмм и пр. Но они были полезны, насколько я сейчас вижу, для понятия общей логики системы, взаимодействия модулей в глобальном масштабе. Ньюансы работы всегда разбирались по коду.
Например, нужно было всем объяснять что для разноски проводки ГК сначала создается журнал. После разноски - журнал может остаться может быть стерт, но он уже не влияет на фин результаты.

[Evgeniy2020]

Цитата:

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

Нет нет нет, нельзя объять необъятное ))
если мы систему до такого уровня представим боюсь что юзабилти упадет до нуля.
нужно будет опять 2 млн квтч в мозгу чтобы ворочать таким муравейником.

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

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



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

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

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

[BOAL]

Про внутреннюю методологию.
Она бывает у внедренца, бывает на внутренний отдел внутри Заказчика. Бывает, что ее и не бывает
Хотя, она есть всегда, просто формы различны - держать все в голове - это тоже методика.
Внедрение или апдайт методологии - это внутренний проект со всеми атрибутами. И порой он сложнее\хуже проекта внешнего. Так как нет внешнего врага (проблемы со стороны), а бороться с собой очень сложно.
Еще сложность из-за того, что методологию нельзя закодить, она на людях, в головах у них кодить сложно, часто сопряжено с "линейкой по рукам" - выработкой условных рефлексов (давать документ в нужном формате, писать код в определенном стиле, выдержать последовательность статусов и тп)

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


То есть, при наличии ответов на первые вопросы и отсутствии широкого инструментария "Чем", можно выкручиваться другими методиками "Как" - что и было описано с картинками уважаемым mazzy (за что отдельное мерси - консультантам ткнул, читать от сих и до обеда, приду проверю ).

[Evgeniy2020]

Ветка умирать не хочет, периодически оживляет себя

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

лучшее враг хорошому
удобство и комфорт враг неудобству и дискомфорту
дешевле враг переплаченному
то что машина великолепно может выполнить пусть выполняет

надо бы книжечку почитать good to great
если в результате этих инструментов система сможет лучше дружить напрямую с бизнес аналитиком и консультантом, кому от этого хуже?

система бизнес friendly, легко и быстро отвечает бизнесу (состоящему из бизнес функций) функциональной картой. Если немного и поменяется методология значит назревало какое то эволюционное изменение давно уже.
в Шур Степе придумали как то моделер

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

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

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

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

[BOAL]

Цитата:

Сообщение от Evgeniy2020

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

Ага, а потом нажмет кнопку и устоит всем ERP Скайнет "хэппи энд" и будут ходить модули системы типа Т-800 по планете и разговарить за жизнь миниганами.

Смотрели
Нам такого будущего не нать. И нью васюков через поколения тоже. Мы ж сегодня живем и работаем.
Но лень двигатель прогресса - потому кто-то особо ленивый когда-нть напишет в АХ получение визуальной дельты функционала на скорм слоев от сервис-паков.

Пока же при желании узнать полный список нововведений в системе, нужно залить сервис пак в ЮСР слой, как ХРО, получить дельту и гулять по ней (функционал папки old в этом плане работает не так качественно, как ХРО заливка).

[Evgeniy2020]

Стоп кран у темы улетел и не обещал вернутся.

Новые инструменты не направлены на изменение методологии.
Еще раз говорю методологию в принципе не меняем.

Цитата:

Вы же пытается идти от концепции "А что система принципиально может". Это в корне неверно.

Честно говоря такой вопрос часто задают наверно Директора предприятий,
особенно на тендерах А что система принципиально может?
и такой же вопрос возникает на GAP анализе, а шо наша система принципально может в такой то и такой то области (учета, планирования, управления).

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

в случае функционального GAP мы и дорисовываем эту функции в системе.
(консультант ТЗ программер вносит эти изменения) создавая наращивая функциональность закрывая GAP.

никто не отменял схему
Бизнес ---> что нужно бизнесу (бизнес аналитик) работает с инвентаризацией и оптимизирует с ключевыми польз. ----> что есть (консультант) пишет тз -------> программист вносит изменения ------> Аксапта (днк в аот)

конечно хуже когда бизнес выравнивается под возможности ERP в корне неправильно от этого бизнес может потерять какие то конкурентные преимущества.

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

только инструменты не меняют саму методологию, они лишь ее ускоряют.
и повышают качество реализации все той же знакомой методологии.

только развитие системы не прекращается они периодически продолжается,
если есть какие то GAP, изменения законодательства, внешние требования на рынке.


вывод инструменты не меняют саму методологию они помогают методологии работать качественнее быстрее дешевле

слава труду

кстати я верю что наверно искусственный интеллект появится где то в аксапте когда в результате развития OLAP и продвинутых средств data mining система вдруг в своем мета коде увидит себя,
сделает выводы, начнется безконтрольный рост репозитария изменений и отражения действительности, репозитарий начнет пухнуть, и система вдруг оживет.