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

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

Хз. Как я писал выше, мне неясно как развивать / реорганизовывать большие (100+) коллективы. Не знаю что тут первым должно быть курица или яйцо.
Маленькие (~10) понятно. Там можно закрыть инициативой снизу при минимальной поддержке руководства. А вот большие хз.

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

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

К сожалению, есть проекты (ГИСы), которые не могут сгореть, их нужно как-то делать. Я про это в основном. В остальном конечно согласен.

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

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

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

Предполагаю, что оба случая, но со вторым я сталкивалась чаще. Например, нельзя так просто взять и изменить какие-то личные сведения гражданина РФ. Очепятались при вводе. Иваноф Иван Иванович, например. Никто не запрещает такую фамилию, и системе совершенно все равно, как оно написано. Ошибка оператора.

Угу. Только полномочия сами по себе не предоставляют возможности быстро набрать ии развить команду. Да даже не быстро, а хотя бы гарантированно. Это в таком случае нужно сделать самому. Каким-то образом, если коллектив велик и беспросветен то хз каким. :)

И хз зачем, вот ещё нюанс :)

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

А что может быть интереснее, чем повысить КПД команды? И научиться повышать КПД у команд? Снизить трудозатраты на внесение изменений. Превратить экспоненту в логарифм или даже прямую )

Что тут сказать, разумно

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

Много чего. Например работать с экспертной командой. И как рядовой участник, и как руковолитель. :D
Повышение КПД, если стартовать с низкой базы. Это история про поиск и обучение персонала. До тех пор пока количество удачных попыток (если каждая пятая будет удачна это хорошо) не приведёт к формированию сильного коллектива. На мой взгляд, это не самая комфортная занятость. И уж точно не быстрая, и не гарантированная с тз результата. Но на вкус и цвет все фломастеры разные. :)
В том что касается лично меня - это не мой фломастер. :)

Ну и нюанс, безотносительно комфорта, ещё и в том. Что какая-никакая гарантия результата (хоть и без привязки ко времени достижения) тут только на малых объёмах. Подход не масштабируется.

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

Мы об одном? Я говорю про развитие коллектива по экспертизе. А не про отладку работы уже сразу крутых ребят. :)