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

[Evgeniy2020]

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

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

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

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

[sukhanchik]

Цитата:

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

Я и предлагаю акутальность репозитария модиф и ведение документации возложить на Аксапту 2009.

А вот это уже неправильный вывод. Т.е. конечно возложить можно все. А сможет ли сама система? Для этого ли она предназначена?
Пример. MS Word - замечательная программа - в ней можно писать различные тексты (к примеру документацию ту же). А может в ней можно и учет вести? Там же все отчеты можно нарисовать? Ну допилим немного макросами? Надеюсь, не возникает мысли что MS Word может вполне заменить Аксапту?

Цитата:

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

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

Вот он - изначальный постулат, на основе которого делается следующие выводы
Вывод 1:

Цитата:

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

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

Вывод 2:

Цитата:

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

Пусть прекрасная система и ведет документацию что и как в ней самой представлено и на модифицировано.
отсюда и возникла идея о АОТ для бизнес аналитиков.

Выводы верные при условии, что верен постулат.
А кто сказал что он верен? Visual C# (С++, Delphi, VBA, и т.д.) - прекрасные языки программирования, на которых можно написать замечательную систему учета модиф. А какова цена этого вопроса?

Некоторые консалтинговые компании ведут учет модификаций в АХ (знаю по собственному опыту). Но система изначально - слабо предназначена для этого. MS Word со своим умением вести учет изменений документов, сравнения версий документов - уже дает 100 очков вперед перед АХ. А есть еще замечательная такая штука, как Sharepoint (которую опять-таки надо настраивать - приводить в вид, удобный для использования).

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

Мой вывод базируется на том, что в свое время (пару лет назад) - один мой знакомый таким образом нашел приемлемую для себя систему багтрекинга. Конечно не идеальную, зато бесплатную и русскую. У него были свои требования к системе (которые сформировались поначалу на основе работы с MS Excel) но где-то процентов на 95 его система удовлетворяла. Он ее немного расширил (добавил пару полей, сделал пяток отчетов) и внедрил в использование. С АХ эта система вообще не знакома и никаким образом не связана.

[coolibin]

Цитата:

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

главный вывод актуальная и правильная документация это залог успеха во всем

Evgeniy2020, странно, что вы такой вывод сделали из написанного sukhanchik. Вывод должен был быть совсем другой. В конце концов, документация ведь не самоцель, можно ее и не писать на бумаге. Только нужно понимать, что если важная информация у вашего специалиста "закеширована", как вы говорите, в голове, то нужно же тогда подстраховаться, чтобы эта голова всегда была под рукой. Но обеспечить доступность этой головы обычно намного дороже получается, чем доступность обычной документации. Формирование документации есть ни что иное, как удешевление процесса передачи знаний из одной головы в другую. Обратите внимание: не удорожание, а именно удешевление. Это не всегда и не для всех очевидно.

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

Почему оно это делало? Хотело как хуже? Да нет, вряд ли. Хотели, скорее всего, как лучше. А лучше всего, им казалось, - сэкономить денег на поддержке системы. Им, возможно, показалось, что все эти методики и технологии придумали жадные и хитрые айтишники, чтобы повытягивать с них денег. Сколько людей на этом уже обожглось, никто, наверное, и не поинтерсовался. Теперь же обнаружилось, что в результате принятой ими политики система внезапно перестала быть дешевой и вдруг оказалась очень дорогой в обслуживании. Ведь, согласитесь, какой вариант вы сейчас не выберите, он в любом случае окажется "дорогим".

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

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

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

[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 система вдруг в своем мета коде увидит себя,
сделает выводы, начнется безконтрольный рост репозитария изменений и отражения действительности, репозитарий начнет пухнуть, и система вдруг оживет.

[Evgeniy2020]

2 Coolibin

Цитата:

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

Очень много неверной информации содержится в этом абзаце. я так не говорил.

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

1. Появился Task recorder. Изменилась ли методология? ответ НЕТ. переложили ли мы труд на Аксапту? ответ ДА. мы облегчили этим жизнь? ответ ДА.
завтра действительно мы несколько поменяем работу одного из пользователей, мы запустим Task recorder достаточно быстро пробежися по новой последовательности. и СИСТЕМА нам выдаст новую инструкцию.
у системы это уйдет 10 секунд и меньше.
Пользователь получит безошибочную новую инструкцию.
(раннее консультант должен был потратить часа два, делать скриншоты,
переделывать инструкцию)

это прямой ответ, я еще приведу примеры.
надо лишь понимать в каких вопросах мы можем применить СИСТЕМУ,
и сделать АВТОМАТИЗАЦИЮ.
я думаю вы знакомы с термином АВТОМАТИЗАЦИЯ это облегчение труда с примением технических систем (в данном случае труд переложен на Аксапту)

такой подход снижает ТСО, снижает трудоемкость, снижает ручной труд, защищает от человеческих факторов.

в моей метафоре присутствует ЧЕЛОВЕК БИЗНЕС АНАЛИТИК, я его никуда не выкидывал, и не сращивал с СИСТЕМОЙ. есть БИЗНЕС АНАЛИТИК есть СИСТЕМА. и консультантов я никуда не выкидывал. их арсенал дополнится уровнем при котором они даже визуально могут видеть труд программиста, и возможно даже смогут ревьюить работу.

я переложил функцию протоколирования изменений на систему в момент фиксирования изменений в АОТ,
да скорее всего я переложу это на СИСТЕМУ. она будет фиксировать изменения системы. чтобы потом творения программера прикрутить к соотвествующему контуру.

и про USAGE COUNTERS я тоже не зря спросил чтобы интервьюирование пользователей то чем они пользуются, переложить на систему, она весьма красиво представит ЧЕМ ПОЛЬЗУЕТСЯ БУХГАЛТЕР ИВАНОВА И.И. система отразит то чем она реально пользуется и покажет чем и чаще чем.

[coolibin]

Цитата:

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

Очень много неверной информации содержится в этом абзаце

Очень здорово, если у вас все не так. Я просто обратил внимание на тот факт, что как аналитик у вас исчез из процесса поддержки системы, так нового, вроде бы, и не стали приглашать.

Цитата:

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

надо лишь понимать в каких вопросах мы можем применить СИСТЕМУ, и сделать АВТОМАТИЗАЦИЮ.
я думаю вы знакомы с термином АВТОМАТИЗАЦИЯ это облегчение труда с примением технических систем (в данном случае труд переложен на Аксапту)

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

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

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

[Evgeniy2020]

2 Colibin, отвечаю вам скорее всего последний раз.

вы читали неверно. никуда бизнес аналитик из поддержки не делся.
точнее так да один ушел. а есть другой прекрасный бизнес аналитик.
но он не знает АОТ, не знает что такое gls usr и часто обращается с вопросом к программисту, мол что у нас в системе есть и как это реализовано.

тема создана как раз чтобы облегчить подобную ситуацию.

Цитата:

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

противоречит здравому смыслу, как раз автоматизация служит для облегчения чьего-либо труда. Отсюда в Excel макросы и VBA.
В Аксапте появился Таск рекордер. Автоматизирование тестирования (тест кейсы)

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

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

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

[oip]

Цитата:

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

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

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

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

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

Цитата:

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

ERP впервую очередь учетная система, поэтому и термины здесь зачастую будут учет)

ERP - это не учетная система. Это система планирования.

P.S. Про планирование Маззи чуть опередил.

[Evgeniy2020]

Цитата:

Никого не волнует "потраченные попусту человеко-часы", если эти часы обходятся дешевле автоматизированной системы.

цена автоматизированной системы на текущий момент складывается из
TCO + TCC = Цена поддержки системы + цена развития.

если для работы системы требуется постояная поддержка консалтинговой компании то ТСО очень высокий (не дешево).

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

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

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

[coolibin]

Цитата:

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

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

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

[Evgeniy2020]

Давайте если возможно прикроем данную ветку. Пусть она в архив уйдет.

Пусть эта ветка была Предпроектным исследованием на тему Нужен ли новый слой АОТ (функциональная карта) для бизнес аналитиков и для людей развивающих (эволюционирующих) ERP системы?

Поможет ли такой слой уменьшить ТСО, ТСС, снизить ли он complexity и бла бла бла.

Если потребуется лучше откроем потом позже уже проектную ветку.

В настоящий момент я начал разбираться с перекрыстными ссылками, элементами АОТ. выбираю формат проекта. так как все таки тема показалась мне перспективной.

пока что склоняюсь к решению сбросить AOT в MS SQL Server. Тогда можно будет удобно все это варить эволюционировать раскладывать.
Конечно придется обновить перекрестные ссылки, кроме того добавить механизм протоколирования изменений в АОТ, авто обновление перекрестных ссылок при обновлении элементов в АОТ. и т.д.

решил следовать формату АХ 6 в которой кажется содержимое aod сбросят в SQL. и тогда появляются вообще там экзотические идеи.
даже OLAP по метакоду можно будет строить

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

2 dn

Цитата:

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

это как раз внедрение СТОИМОСТНОГО ПРОЦЕССНОГО ПОДХОДА.
когда при моделировании зачастую применяют процессный подход (бизнес моделирование)
и подсчитывают кост отдельно взятых процессов. естесвенно автоматизация может уменьшить косты в отдельных процессах, что повысит прибыльность бизнеса ка одной из целей бизнеса itself.
(кстати хорошая идея в последствии в функциональную карту прикрутить процессный подход)

кстати по поводу термина ERP да было раньше MRP, потом немножко выросло и стало ERP. но сами системы давно в себя включают не только планирование, но и сбор факта через учет и измерение, и также управление.
можно было давно дать термин EM Enterprise management.
или ERM Enterprise resource management.

Enterprise Resource Planning (ERP) is an integrated computer-based system used to manage internal and external resources, including tangible assets, financial resources, materials, and human resources. Its purpose is to facilitate the flow of information between all business functions inside the boundaries of the organization and manage the connections to outside stakeholders. Built on a centralized database and normally utilizing a common computing platform, ERP systems consolidate all business operations into a uniform and enterprise-wide system environment.


http://en.wikipedia.org/wiki/Enterpr...ource_planning