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

[sukhanchik]

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

Цитата:

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

Хорошо, начнем анализ на примерах.
Присутствует свой программист Аксапта с 2006 го. Который локально внутри компании развивает систему и производит критические правки и доработки. Никакая документация этим программистом не ведется.
Сам программист не имеет свободного времени. полностью занятый ресурс.

Ошибка руководства компании №1. Отсутствие ведения документации означает, что, экономя на ведении документации - мы автоматически предполагаем что единственная документация - это программный код. Значит бизнес-аналитик / консультант / кто-то еще ДОЛЖЕН разбираться в коде (=быть программистом). Такой специалист дороже неразбирающегося в коде аналитика. Но мы же экономим на документации, значит мы должны осознавать что кроме кода у нас ничего нет. Если руководство это не осознает (не осознавало) - это ошибка руководства. Неважно когда допущенная. Грамотное руководство должно грамотно считать затраты. Если оно считает затраты неграмотно - это неграмотное руководство.

Цитата:

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

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

Вот и вскрылась цена отказа от ведения документации.

Цитата:

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

имеем текущий проект переходим на AX 2009 SP1 RU5
цель проекта отчистить систему от мусора и кустарщины по возможности перейти на стандртную функциональность АХ 2009.
Решили взять слои VAR CUS USR перенести в АХ 2009. получим копию Аксапта 3.0 только на платформе АХ 2009. На текущий момент ни в консалтинговой компании на которой завязан переход, ни в самой компании А нет людей которые СХОДУ могли бы сказать, что является доработкой а что теперь есть в новом стандарте АХ 2009 в качестве аналогов. В итоге тот же хлам который обширно написан на Ах 3.0 переносится на АХ 2009.

Да, но компания сама же отказалась от учета хлама.

Цитата:

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

И теперь вопрос как действительно и эффективно избавится от хлама, написанного за 4 года и перейти и задействовать новый стандарт АХ 2009 (стандартную функциональность)

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

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

Цитата:

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

В компании была принята ранне схема
Бизнес ------> Бизнес аналитик говрит что нужно бизнесу ------> консультант знает что есть пишет тз -----------> разработчик кодирует изменения ---> Аксапта 3
консультанта в настоящий момент времени нет. переложено на консалтинг но сами люди часто меняются.
поэтому осталось
Бизнес -----> Бизнес аналитик -----------> Программист ---> Аксапта 3.0
текущий проект
Аксапта 3.0 ------> Косалтинг консультант и программист + слои VAR CUS USR -----> Ax 2009

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

Цитата:

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

консалтинг старается минимизировать свои усилия,

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

Цитата:

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

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

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

Цитата:

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

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

Конечно. Проще было тщательно вести документацию.

Цитата:

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

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

Полный анализ "с нуля". Т.е. описание всех бизнес-процессов, описание того, как они отражаются в системе. Моральная подготовка к тому, что если что-то забыли описать - то это отвалится. Пусть у Вас 60% уже есть. Отлично - значит Вам нужно провести анализ по 40%, все склеить и подходить к внедрению, как будто все делаете с нуля. Посмотреть - что есть в АХ 2009 - какие процессы ложатся на стандарт, какие требуют изменений. Может какие-то бизнес-процессы пересмотреть в угоду экономии на модицикациях.
Нацелиться на час Х. Морально быть готовым, что еще несколько месяцев система будет "утрясаться".
Ну и вести документацию.

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

[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]

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. Про планирование Маззи чуть опередил.

[coolibin]

Цитата:

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

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

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