ТЗ как обязательный атрибут в автоматизации. Реальные кейсы из 16-ти летнего опыта

Публикация № 1669511 01.06.22

Управление - Анализ и проектирование ИТ-систем

Техническое задание – документ, который многим кажется слишком дорогим удовольствием. Руководитель консалтингового направления ГК СофтБаланс Клавдия Макарова объяснила, почему нельзя на него смотреть только с этой точки зрения, и какую пользу он приносит команде и заказчику.

Тема моего доклада – техническое задание как обязательный атрибут в автоматизации. Мы разберем реальные кейсы из моей 16-летней проектной практики.

В ходе доклада мы будем постоянно обращаться к регламенту по ТЗ, который используется в моей команде.

 

О себе

 

  • Я руковожу консалтинговым направлением в группе компаний СофтБаланс.

  • В проектной деятельности я более 16 лет.

  • Начинала с московского франчайзи, потом работала в фирме «1С», в «Учебном центре №3», и даже проводила сертификацию преподавателей ЦСО по бухгалтерскому учету в 1С – принимала экзамены.

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

  • Также я являюсь профессиональным корпоративным спикером.

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

 

В поисках универсального подхода

 

Вкратце расскажу про свой 16-летний опыт.

Начинала я как консультант горячей линии. Будучи по натуре аналитиком, я не могу не анализировать всю информацию, которая ко мне приходит. И все 16 лет я искала этот «философский камень» написания технического задания.

Мне удалось поработать с большим количеством программистов, и я убедилась, что подход к ТЗ у всех разный. Передо мной в свое время даже стояла задача – понять программистов, придумать, как работать с различными специалистами по каким-то одинаковым критериям. Оказалось, что это невозможно. Тогда я для себя придумала идею, что программист – это художник. Когда художник рисует, он может одну и ту же картину нарисовать абсолютно разными красками, абсолютно по-разному наложить слои. И когда я придумала себе такую ассоциацию, мне стало немного легче.

Когда я уже работала бизнес-архитектором, я знала всех программистов у нас в компании. У нас, как и во многих других франчайзи, есть пул абсолютно разных специалистов, каждого из которых я могла подключить на проект. Я знала их всех наизусть – знала все нюансы и подходы, знала, какого программиста надо 2-3 раза проверить, а кого проверять не надо и можно даже попросить ещё кое-что сделать. Это было очень забавно, как какая-то игра.

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

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

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

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

 

ТЗ: для кого и для чего

 

 

Давайте разберемся, для кого и для чего нужно техническое задание, на чем оно базируется, на что нужно обратить внимание?

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

Мы делаем ТЗ, чтобы максимально снизить риски. Заказчику важны деньги – он должен понимать, за что он их платит, а мы все-таки продаем не шоколадные батончики, когда можно четко сказать, сколько это стоит.

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

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

Поэтому ТЗ – это инструмент управления рисками. И в принципе любая документация на проекте нужна для снижения рисков.

Остановимся на некоторых моментах подробнее.

Хочу начать с цитаты моего коллеги, технического руководителя Олега Олейниченко.

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

Получается, что аналитик – это некий «универсальный солдат»: ему нужно донести информацию и до заказчика, и до программиста, и дать оценку руководителю проекта.

А со своей стороны мы, руководители проектов, руководители направлений и отделов, должны обеспечивать аналитиков нужной информацией.

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

 

Ключевые положения регламента по составлению ТЗ

 

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

  • быть понятными;

  • конкретными;

  • и тестируемыми.

 

Кейс №1: когда ТЗ не нужно

 

Рассмотрим, в каких случаях техническое задание не нужно.

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

Сюда можно отнести задачу уровня «добавить новый реквизит с типом Строка в документ Реализация товаров и услуг». Правда, исходя из моего опыта, мне в этой постановке не хватает длины этой строки, понимания, многострочная строка или нет и т.д. Поэтому, в зависимости от того, кому вы даете эту задачу – опытному или начинающему программисту – уточнения все-таки могут потребоваться. Но если мы знаем уровень разработчика, который будет делать эту задачу, мы понимаем, как с этим работать.

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

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

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

Паспорт проекта можно вести в СППР – не все эту систему используют, но у всех, кто работает с 1С, к СППР есть доступ. Что бы ни говорили о сложности СППР, в ней, как минимум, можно фиксировать требования и вести паспорт проекта.

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

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

Еще ТЗ не нужно, когда важна скорость проверки гипотез. Здесь клиент просто не согласится на длительное согласование ТЗ, ему нужна скорость – нужно проверить одну, вторую, третью гипотезу.

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

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

 

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

Когда у вас уже есть каркас решения – например, в точках Т3 и Т4, время и стоимость могут кардинально увеличиться, а приращение качества и точность прогноза уже не достигаются. Поэтому было бы здорово, если бы вы понимали и чувствовали, когда нужно остановиться в улучшении технического задания.

Вам в этом плане поможет совокупность «техническое задание – система учета задач – паспорт проекта». Если эти три инструмента работают в связке, они вам дальше помогут.

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

 

Кейс №2: не решайте за программиста

 

 

Посмотрим еще один кейс. Я всегда говорю: не решаете за программиста, как нужно делать ту или иную задачу технически. Это может быть оправдано, только если он – простой кодер или начинающий специалист.

 

У меня был случай, когда я, будучи еще простым аналитиком, готовила для проекта концептуальную модель и задала своему руководителю проекта вопрос: «Кто из программистов будет это разрабатывать?». На что руководитель проекта сказал, что меня это не должно волновать, это вопрос будущего – когда начнется разработка, тогда и станет ясно.

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

В любом другом случае – если на проекте работают опытные специалисты – описывайте в ТЗ только идею, прорабатывайте детально только некоторые моменты ТЗ.

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

Я помню свое негодование, когда программист сделал все не по моему ТЗ и, не спрашивая меня, перевел допреквизит во встроенный реквизит.

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

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

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

Не пишите техническое задание куском кода. Это, конечно, большая «боль». Пока я росла, как аналитик, разные руководители проекта требовали от меня писать ТЗ абсолютно по-разному, в том числе и просто кодом. Из-за этого мне казалось, что новые аналитики, которых я беру в свою команду, тоже должны писать ТЗ куском кода. Это неправильно. Зачем нам программисты тогда?

И не нужно забывать, что такое техническое задание. Помимо того, что это прогнозирование будущего, это еще и документ, который вас обезопасит. Клиент должен прочитать, он должен понять, о чем идет речь, и подписать этот документ. Он должен быть готовым поставить подпись под тем, что понимает все, что в ТЗ написано.

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

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

 

Кейс №3: ТЗ – совместный труд аналитика и программиста

 

Давайте посмотрим еще один кейс, который доказывает, что ТЗ – это совместный труд аналитика и программиста.

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

Аналитик пишет техническое задание, базирует на этом документе отчет.

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

 

 

Если на момент написания технического задания аналитик и программист не будут взаимодействовать, что мы получим неприятные нюансы:

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

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

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

Поэтому ТЗ – это труд совместный. Нужно взаимодействовать.

 

Кейсы №4, 5, 6. Описывайте реквизиты, визуализируйте диалоговые окна и печатные формы

 

В ТЗ рекомендую оформлять реквизиты в виде таблицы. Это очень важно.

 

Обязательно визуализируйте формы.

 

 

Это можно делать в Excel.

 

 

Или в 1С Maker.

 

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

 

Сценарии тестирования

 

 

И, наконец, сценарии тестирования. Это – то, что поможет программистам. Если у вас есть сценарии тестирования, программист сможет проверить, как с этим работать.

В сценариях тестирования нужно обязательно определять:

  • входящие данные;

  • ожидаемый результат, который считается «хорошим».

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

Сценариев тестирования может быть достаточно много.

На слайде показан маленький пример.

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

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

 

Дополнительные рекомендации для работы со сценариями тестирования:

  • если есть расчетные цифры, нужно давать конкретные расчетные данные;

  • если есть вариативность получения результата, пишите в сценарии все варианты;

  • идеально, если в базу будут заведены данные, на которых нужно тестировать.

 

Итоги

 

 

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

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

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

 

Вопросы

 

Дайте определение, что такое ТЗ с вашей точки зрения, и что такое паспорт проекта, о котором вы упоминали. Потому что разные люди вкладывают в эти понятия разные вещи.

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

А как соотносятся понятия «паспорт проекта» и «устав проекта»?

Давайте не путать устав проекта, с которым работают руководители, и паспорт проекта, с которым работают программисты. Для меня паспорт проекта – это не ключевые вводные по проекту и не оргструктура. Паспортом проекта я называю систему, с которой мы работаем, она так и называется «Паспорт проекта». В ней ведется именно технический проект, техническая информация, по каким требованиям какая реализация сделана.

Учитывается ли длина жизненного цикла информационной системы при определении нужности ТЗ? При добавлении одного реквизита или для систем с коротким жизненным циклом ТЗ действительно не нужно. А если жизненный цикл системы больше 20-40 лет, лучше писать ТЗ или вносить изменения в существующее ТЗ и вести историю изменений?

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

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

В любом случае, эффективна связка трех подходов: «ТЗ – система учета задач – паспорт проекта».

Например, мы в команде для этого используем систему учета задач – заводим задачу, где четко видно, что и как. И параллельно в системе техпроекта мы фиксируем, что был добавлен такой-то реквизит, такая-то роль по требованию из Redmine под номером таким-то. Связка сохраняется, и через 40 лет информация будет актуальна.

ТЗ для заказчика и для программиста – это два совершенно разных документа, два разных видения. Можно ли эти видения совместить в рамках одного документа? И хороша ли эта практика?

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

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

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

Я обычно говорю так: если клиент что-то хочет, мы всегда соглашаемся, но… И в это «но» мы уже дописываем все, что нужно. А дальше уже все решает мастерство руководителя проекта – переговорные моменты и т.д.

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

Есть ли какой-то стандарт по написанию ТЗ или «что хочу, то пишу, я руководитель проекта, мне виднее»?

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

Я уверяю, что многие аналитики даже не знают, что такие материалы есть в Профкейсе, это то, что рекомендует сама фирма «1С» – вы как сотрудники фирмы-франчайзи имеете право на эти документы посмотреть.

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

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

Поэтому есть общие какие-то моменты, на что нужно обращать внимание, есть регламент системы менеджмента качества (СМК), который спускает вендор. А дальше уже все решают ваш опыт, творчество и умение творить чудеса.

 

*************

Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе "Сбор требований и составление ТЗ: современные подходы в управлении проектами". Больше статей можно прочитать здесь.

Приглашаем всех 6-8 октября принять участие в INFOSTART EVENT 2022 в Санкт-Петербурге: //infostart.ru/events/1573038/

*************

Специальные предложения

Оставьте свое сообщение

См. также

Путь покупателя интернет-магазина (Customer Journey) с использованием УФМТП Промо

Анализ и проектирование ИТ-систем УУ Бесплатно (free)

Недавно у меня вышла статья под названием «Универсальная функциональная модель торгового предприятия (УФМТП) в нотации IDEF0». И одно из пожеланий читателей было пояснить подробнее, как я лично пользуюсь этой моделью и как вообще ее можно применять на практике. В этой статье я выполню просьбу читателей. И на примере взаимодействия покупателей с интернет-магазином продемонстрирую практическое применение этой модели.

12.05.2022    570    raiml    2    

Автоматизация vs оптимизация

Анализ и проектирование ИТ-систем Внедрение ИТ-системы Бесплатно (free)

Анализ и оптимизация бизнес-процессов становятся все более востребованными в проектах автоматизации, а с массовым переходом с 1С: УПП на 1С:ERP эта задача станет еще более актуальной. О том, как собрать полную картину реальных потребностей вашего заказчика, исходя из логики его бизнес-процессов, на конференции Infostart Event 2021 Moscow Premiere рассказала Елена Иванова.

27.06.2022    387    e_ivanova    0    

Скальпель, зажим, … пластырь, валерьянка. Мы закончили..: инструменты работы бизнес-аналитика

Анализ и проектирование ИТ-систем Бесплатно (free)

Считается, что аналитику для работы на проекте достаточно уметь строить бизнес-процессы в одной-двух популярных нотациях. Но это не так, потому что работа аналитика гораздо разнообразнее и не ограничивается рисованием схем. О том, какие инструменты пригодятся аналитику и помогут ему сделать свою работу комфортной и удобной, на конференции Infostart Event 2021 Moscow Premiere рассказала руководитель отдела сопровождения финансового учета компании «Самокат» Анастасия Штей.

23.06.2022    1879    ashtey    0    

Эмпатия и системный подход в сборе требований и составлении ТЗ

Анализ и проектирование ИТ-систем Внедрение ИТ-системы Бесплатно (free)

Начальник отдела внедрения и сопровождения информационных систем в торговой сети «Командор» Елена Качаева выступила на митапе «Сбор требований и составление ТЗ». Елена рассказала, как разобраться в особенностях клиента, как найти с заказчиком общий язык и составить корректное ТЗ, которое в дальнейшем будет легко реализовать и сдать.

10.06.2022    1080    kacelena    2    

Универсальная функциональная модель торгового предприятия в нотации IDEF0 Промо

Анализ и проектирование ИТ-систем УУ Бесплатно (free)

Из чего состоит предприятие? Какие функции основные, а какие нет? В данной статье вы найдете ответ на этот и другие вопросы. Модель, построенная на основе опыта бизнес-консультанта с использованием нотации IDEF0.

12.05.2022    835    raiml    4    

Аналитика и BI. Белые пятна рынка и тренды, которые нельзя игнорировать

Анализ и проектирование ИТ-систем Консолидация данных Бесплатно (free)

Мир вычислений бурно развивается, и потребность анализировать «большие данные» уже плотно вошла в жизнь любой, даже маленькой компании. О том, какие исторические предпосылки привели к текущей ситуации на рынке BI-систем, и какие перспективы у этого развития, на митапе «Бизнес-анализ по данным базы 1С» рассказали представители компании «Консон» Евгений Скребанов и Иван Мищенко.

08.06.2022    1013    imischenko    0    

SAFe Epic (Эпик)

Анализ и проектирование ИТ-систем Бесплатно (free)

Перевод https://www.scaledagileframework.com/epic/, с переводом сопутствующих терминов, для понимания основного термина и варианта его использования.

06.06.2022    517    malikov_pro    0    

Современные СЭД: курс на упрощенчество и подмена понятий

Документооборот и делопроизводство Анализ и проектирование ИТ-систем Внедрение ИТ-системы УУ Бесплатно (free)

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

12.05.2022    435    user1214797    5    

Кто такой архитектор? Системный или функциональный? Статья 1 Промо

Анализ и проектирование ИТ-систем Бесплатно (free)

Часто сталкиваюсь с непониманием того, кто такой архитектор. Во многих командах эту компетенцию не используют, либо используют неверно. В связи с непониманием того, как устроен процесс разработки в сфере 1С и кто за что отвечает, будут написаны 8 статей. Это первая статья. В статье постараюсь раскрыть роль архитектора и его значимость в процессе проектирования и разработки. Основываюсь на своём опыте (более 15 лет). Для написания этой статьи изучал статьи на эту тему от коллег и консультировался с руководителями крупных команд.

30.06.2020    26469    biimmap    74    

Business Objective Model или Модель бизнес-целей - где, зачем и как применять?

Анализ и проектирование ИТ-систем Бесплатно (free)

Модель бизнес-целей или Business Objective Model (далее BOM) - техника, которая захватила моё сердце и разум с первого взгляда. Простая и наглядная, она помогает избежать того, от чего так часто возникает недопонимание между бизнесом и теми, кто его автоматизирует.

23.03.2022    1596    SerjoginaMaria    18    

Power BI дешево или очень дорого?

Консолидация данных Анализ и проектирование ИТ-систем Бесплатно (free)

На онлайн митапе «Бизнес-анализ по данным базы 1С. Интеграция c платформами BI» выступил Петр Базелюк, CTO компании Digital Business. Петр рассказал, как запустить систему аналитики для полноценной цифровизации всего бизнеса, сравнил возможности подписок Free, Pro и Premium и подсказал возможные пути минимизации затрат.

18.02.2022    2026    pbazeliuk    2    

Какие риски и ответственность берет на себя бизнес-аналитик

Анализ и проектирование ИТ-систем Бесплатно (free)

Профессия бизнес-аналитика хотя и интересная, но полна неопределенности. Чем должен заниматься этот специалист, какими навыками обладать, за что отвечать? На эти вопросы попытался ответить исполнительный директор Инфостарта Александр Чавалах.

16.02.2022    2285    chavalah    8    

Ошибка №1 внедрения "Бюджетирования" в 1С:ERP2 и 1С:КА2: настройка статей бюджетов и статей ДДС 1-в-1 Промо

Бюджетирование и планирование Внедрение ИТ-системы Анализ и проектирование ИТ-систем v8 ERP2 КА2 Россия УУ Бесплатно (free)

В цикле статей я хочу поделиться ошибками во внедрении подсистемы «Бюджетирование», которые мне приходится исправлять после коллег на реальных проектах, и лучшими приемами по автоматизации бюджетирования на 1С:ERP 2 и 1C:КА 2. Сегодня поговорим и о самой распространенной ошибке – настройке статей бюджетов 1-в-1 к справочнику «Статьи ДДС».

13.06.2018    38383    SergeyN    96    

Как из 1С отдать миллионы строк в BI и успеть это сделать быстро

Консолидация данных Анализ и проектирование ИТ-систем WEB v8 Бесплатно (free)

На онлайн-митапе «Бизнес-анализ по данным базы 1С. Интеграция c платформами BI» выступил ведущий разработчик WiseAdvice.tech Дмитрий Фурцев. Дмитрий рассказал о том, как отдать миллионы строк из 1С в платформу бизнес-аналитики и не потратить на это сутки.

14.02.2022    3523    Fudj1k    11    

Как мы подружили "1С:Аналитику" и "Финансист". Практический опыт

Консолидация данных Внедрение ИТ-системы Анализ и проектирование ИТ-систем Бесплатно (free)

«1С:Аналитика» – достаточно молодой инструмент от фирмы «1С». О том, как его настроить и запустить для отображения консолидированных данных из различных баз, на митапе «Бизнес-анализ по данным базы 1С. Интеграция с платформами BI» рассказала Ирина Богданова – ведущий разработчик тиражного решения «Финансист» в компании WiseAdvice.

11.02.2022    1907    bogira    2    

Не надо делать мне как лучше, оставьте мне как хорошо

Анализ и проектирование ИТ-систем 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

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

08.02.2022    3045    SerjoginaMaria    36    

IDEF0. Знакомство с нотацией и пример использования Промо

Анализ и проектирование ИТ-систем Обучение, бизнес-тренинг, курсы 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

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

28.06.2017    51606    raiml    37    

42 или главный вопрос по бизнес-процессам

Анализ и проектирование ИТ-систем Бесплатно (free)

Приветствую вас, уважаемые коллеги! Меня зовут Анастасия Штей, я – бизнес-аналитик 1С. Именно так я начинала свои доклады на INFOSTART EVENT 2021 Post-Apocalypse и INFOSTART EVENT 2021 Moscow Premiere. Мне очень близка тема бизнес-анализа, изучения подходов и практик моделирования бизнес-процессов и компетенции бизнес-аналитика. И сейчас я запускаю на Инфостарт серию статей, а уже скоро и курс, посвященный основам моделирования и анализа бизнес-процессов.

07.02.2022    4199    ashtey    20    

Документальное оформление бизнес-процессов в проектах по автоматизации

Анализ и проектирование ИТ-систем Управление проектом Внедрение ИТ-системы Бесплатно (free)

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

02.02.2022    2836    denisgalimoff    2    

Как бизнес-аналитик может повысить эффективность и прибыльность разработчиков

Управление ИТ-подразделением Анализ и проектирование ИТ-систем Бесплатно (free)

Эксперты не устают спорить, насколько важны аналитики, какие функции они должны выполнять, как взаимодействовать с другими ролями в проекте. О том, как привлечение бизнес-аналитиков помогло увеличить эффективность разработчиков, рассказал директор и ведущий разработчик украинской компании «Арт Порт» Максим Артёменко.

31.01.2022    1238    drmaxart    2    

Краткое описание BPMN с примером Промо

Анализ и проектирование ИТ-систем Бесплатно (free)

О том, что такое BPMN, написано очень много. Но проблема в том, что почти вся информация, которую можно найти в Интернет, ориентирована на людей, которые уже ранее сталкивались с BPMN или с другим стандартом моделирования бизнес-процессов. Я же предлагаю разобраться «с нуля» — что такое BPMN? В чем особенности и преимущества этой технологии и почему она появилась и оказалась столь востребованной, по крайней мере, за рубежом. Да и у нас в стране ей все больше и больше интересуются.

28.06.2017    38689    raiml    10    

Матрица компетенций аналитика 1С

Мотивация, лидерство и личная эффективность Анализ и проектирование ИТ-систем Бесплатно (free)

Тема мотивации сотрудников – одна из центральных в любой организации. Но, как и за что премировать работников, определиться сложно. В компании ФТО решили, что нужно сформировать матрицу компетенций, присвоить каждой определенное количество баллов, и уже на основании такой независимой оценки распределять премиальные. Подробнее о системе рассказала руководитель аналитиков 1С проектного отдела компании ФТО Анна Бирюкова.

28.01.2022    2369    abir    20    

Экспресс-обследование и реинжиниринг бизнес-процессов

Внедрение ИТ-системы Управление проектом Анализ и проектирование ИТ-систем Бесплатно (free)

Проведение обследования – это первый этап работы на проекте. От того, как этот этап пройдет, и какие результаты будут получены, будет зависеть дальнейший исход вообще всего проекта. О проведении обследования предприятия для целей управленческого учета на основе МСФО рассказал Генеральный директор ООО «Рэй Консалтинг» Николай Шилкин.

26.01.2022    1744    RayCon    0    

Бизнес-аналитики 1С: спрос есть, но кто они?

Управление ИТ-подразделением Внедрение ИТ-системы Анализ и проектирование ИТ-систем Бесплатно (free)

Каждый понимает по-своему, кто такой бизнес-аналитик и чем он занимается. Руководитель компании CORS Consulting Илья Отькало постарался ответить на вопросы, что должен знать такой специалист, какие знания и навыки ему пригодятся в работе.

24.01.2022    3691    otkalo    0    

Про спагетти, или как исследовать бизнес-процессы организации Промо

Анализ и проектирование ИТ-систем Бесплатно (free)

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

23.02.2017    29016    Gavrik    11    

Роль и задачи аналитика в проектной команде при внедрении 1С

Управление командой Внедрение ИТ-системы Анализ и проектирование ИТ-систем Бесплатно (free)

Типовые продукты фирмы «1С» становятся все более гибкими, и функция разработки или изменения для них очень часто вообще не требуется или требуется точечно, поэтому для подобных проектов появился отдельный специалист – аналитик 1С. Какие у него задачи, и чем он отличается от системного аналитика и бизнес-аналитика, рассказал руководитель отдела экспертизы компании «Первый БИТ» Денис Галимов.

19.01.2022    4876    denisgalimoff    8    

Как быстро нарисовать блок-схему или изобразить бизнес-процесс

Анализ и проектирование ИТ-систем Россия Бесплатно (free)

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

25.11.2021    4859    VachKirp    7    

Как оценивать задачи программисту 1С Промо

Анализ и проектирование ИТ-систем Россия Бесплатно (free)

Оценивать задачу всегда сложно. У меня не всегда получается оценивать задачи адекватно (во всяком случае, не всегда моё ощущение адекватности совпадает с ощущениями других участников процесса). Именно по причине того, что вопрос для меня актуальный, хочу поделиться своими размышлениями, субъективным опытом в этом вопросе. Речь пойдет только о технической оценке.

11.08.2016    38049    SamBadi    55    

Реактивный интерфейс для 1С:Предприятия

Работа с интерфейсом Анализ и проектирование ИТ-систем Бесплатно (free)

Интеграция 1С:Предприятие с веб-приложениями требует нестандартных решений. О том, как построить веб-интерфейс для 1С на HTTP-сервисах, и какие технологии при этом можно использовать, на митапе «Интерфейс в 1С» рассказал автор профессиональных курсов по JavaScript в HTML Academy Игорь Антонов.

27.10.2021    4322    antonov_i    17    

Модель C4 (C4 model) для визуализации архитектуры программного обеспечения

Анализ и проектирование ИТ-систем Бесплатно (free)

Перевод главной страницы сайта https://c4model.com/, посвященной C4 model.

26.10.2021    3768    malikov_pro    10    

Использование PlantUML в Redmine

Анализ и проектирование ИТ-систем Бесплатно (free)

В статье опишу порядок настройки плагина PlantUML для Redmine 4.2

25.10.2021    707    malikov_pro    2    

Как теряют бизнес. Реальные истории от бизнес-консультанта. Промо

Анализ и проектирование ИТ-систем Бесплатно (free)

Поговорить о том, какие причины способствуют гибели существующего и часто даже успешного на определенном этапе бизнеса, я планировал давно, но все не доходили руки. Но недавно я услышал о банкротстве моего, теперь уже, клиента. Именно этот факт стал для меня неким толчком. Я осознал, что именно сейчас, в условиях кризиса очень важно понимать, почему бизнес может окончиться крахом и учиться избегать подобных ситуаций. Как известно, когда в экономике кризис, любой бизнес ослаблен. Если сравнивать с человеческим организмом, то кризис для экономики – как ослабление иммунитета. Когда человек здоров, то мелкие болезни проходят незамеченными. Организм сам справляется с проблемами, а в случае ослабления иммунитета, любая инфекция может привести к серьезным заболеваниям или даже стать фатальной. Так происходит и в бизнесе. Если в период подъема экономики какие-то недостатки конкретного бизнеса сглаживаются, остаются незамеченными и даже не слишком мешают работать, то в периоды экономического спада они становятся теми самыми «тонкими местами», которые приводят к снижению прибыли, к определенным проблемам, а иногда даже к полному краху всего бизнеса.

06.04.2015    38826    raiml    14    

Уникальный дизайн в 1С на примере разработки реального продукта

Работа с интерфейсом Анализ и проектирование ИТ-систем Бесплатно (free)

Изменить стандартный дизайн интерфейса в 1С можно не только с помощью классических веб-технологий. О том, как для этой цели использовать SVG-картинки, и какие особенности есть у такого подхода, рассказал разработчик 1С в компании «Ангелы ИТ» Сергей Харламов.

18.10.2021    10257    zatoichi    37    

Когда интерфейсам 1С нужны веб-технологии

WEB Работа с интерфейсом Анализ и проектирование ИТ-систем Бесплатно (free)

Есть несколько способов сделать интерфейс в 1С богаче и оптимальнее с помощью веб-технологий. О том, какие практические приемы помогут в этой задаче, на митапе «Интерфейс в 1С» рассказали руководители разработки в компании «Арбис» Матвей Серегин и Анна Гнатюк.

15.10.2021    3960    Akcium    10    

Из арт-директора веб-студии в команду разработки продукта на платформе 1С

Работа с интерфейсом Анализ и проектирование ИТ-систем Бесплатно (free)

В мире 1С по сравнению с веб-разработкой незаслуженно мало внимания уделяется поведению и внешнему виду интерфейсов. На митапе «Интерфейс в 1С» руководитель группы разработки компании АРБИС Анна Гнатюк рассказала, что она привнесла из большого мира дизайна в разработку на 1С.

13.10.2021    1271    gntk    2    

Детские механизмы для взрослых людей

Мотивация, лидерство и личная эффективность Анализ и проектирование ИТ-систем Бесплатно (free)

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

06.09.2021    1767    ashtey    6    

Решение детективных задач

Анализ и проектирование ИТ-систем v8 1cv8.cf Бесплатно (free)

Пробуем систематизировать методы решения детективных задач

25.08.2021    4117    1c-intelligence    31    

Берримор, ты потерял рецепт овсянки? Не беда, нам поможет DFD!

Анализ и проектирование ИТ-систем Бесплатно (free)

Методология DFD наряду с нотациями IDEF0 и IDEF3 входит в тройку популярных методологий описания бизнес-процессов. Мы не говорим о современных нотациях eEPC или BPMN, мы говорим о классике.

16.08.2021    4831    ashtey    2    

Склад Готовой Продукции – отказать, прямое распределение. Промо

Анализ и проектирование ИТ-систем Оптовая торговля, дистрибуция, логистика УУ Бесплатно (free)

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

27.02.2015    28292    izidavld    69    

Мухи отдельно, котлеты отдельно. Или когда использовать IDEF3?

Анализ и проектирование ИТ-систем Бесплатно (free)

С нотацией IDEF0 разобрались, теперь поговорим о следующем представителе семейства IDEF – нотации IDEF3.

08.08.2021    4419    ashtey    6    

Управление моделями при сборе требований

Анализ и проектирование ИТ-систем УУ Бесплатно (free)

От качественного моделирования и документирования бизнес-процессов во многом зависит правильность реализации требований заказчика в системе. О том, как организовать процесс моделирования при сборе требований – какие инструменты/нотации при этом использовать и как подбирать аналитика, который сможет правильно документировать требования на проекте, рассказал руководитель проектного отдела “Корпоративные финансы” компании WiseAdvice, Сергей Наумов.

16.07.2021    2726    SergeyN    7    

"Бескомпьютерная" автоматизация Промо

Анализ и проектирование ИТ-систем Внедрение ИТ-системы Россия Бесплатно (free)

Новое, хорошо забытое старое. Недавно решали проблему в логистике, и я вспомнил статью про автоматизацию без компьютеров, основанную на системе "канбан". Канбан система - система эффективной синхронизации многоэтапного производства и материально-технического обеспечения, осуществляемая с помощью карточек производственного заказа и карточек отбора (карточек канбан). Канбаном часто называют всю систему организации производства Toyota Motor Company, считая его почти синонимом данной системы. Это не совсем точно. Канбан - только один из элементов Toyota Production System (TPS). Канбан как инструмент предложил один из создателей TPS - Таичи Оно. Хотя он утверждает, что придумал его вместе с рабочими для упрощения управления на местах.

17.08.2007    32295    support    32    

Краткий путеводитель по методологиям и нотациям описания и моделирования бизнес-процессов. Часть 4

Анализ и проектирование ИТ-систем УУ Бесплатно (free)

Сколько бизнес-аналитиков – столько и мнений: какая нотация лучше и какую следует использовать при моделировании бизнес-процессов. Рассмотрим следующую группу нотаций…

01.06.2021    6074    ashtey    1    

miniCIO: Исполнитель задач или партнер?

Управление ИТ-подразделением Анализ и проектирование ИТ-систем Бесплатно (free)

Что нужно бизнесу – простое решение его задачи «в лоб» или получение реальной пользы и ценности? А как обосновать, что это реальная ценность, даже если запрашиваемая система не будет внедрена, а всего лишь будут «исправлены» текущие бизнес-процессы? Вопросы очень дискуссионные и не имеют однозначных ответов. Попробуем найти решения. Если вы – программист или даже программист 1С, если вам неинтересно понять, почему бизнес развивается так, а не иначе, то эта статья не для вас. А вот если вам небезразлично развитие и функционирование вашего ИТ-отдела, вам интересны процессы и закономерности – читаем до конца и комментируем.

23.05.2021    1405    ashtey    1    

Краткий путеводитель по методологиям и нотациям описания и моделирования бизнес-процессов. Часть 3

Анализ и проектирование ИТ-систем УУ Бесплатно (free)

Итак, сейчас рассмотрим уже самые разнообразные графические нотации и начнем с очень неожиданной – ДРАКОНа.

03.05.2021    5055    ashtey    13    

Автоматизация бизнес-процессов как способ выявления потерь производства Промо

Анализ и проектирование ИТ-систем Бесплатно (free)

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

09.12.2013    23114    pro-rok    15    

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

Анализ и проектирование ИТ-систем УУ Бесплатно (free)

Самая суть – графическая нотация моделирования бизнес-процессов. Какие бывают и когда их использовать… Начнем с семейства нотаций IDEF.

22.04.2021    10860    ashtey    1    

Краткий путеводитель по методологиям и нотациям описания и моделирования бизнес-процессов. Часть 1

Анализ и проектирование ИТ-систем УУ Бесплатно (free)

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

19.04.2021    22455    ashtey    6