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

Публикация № 1674776 10.06.22

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

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

В 1С я работаю более 13 лет, являюсь разработчиком. На данный момент – руковожу техподдержкой, а также участвую в проектах.

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

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

Наша организация – торговая сеть «Командор». В ее состав входит более 300 магазинов – гипермаркетов, супермаркетов, дискаунтеров. Мы находимся в четырех регионах России – это Красноярский край, Республика Хакасия, Тыва и Иркутская область.

 

У нас достаточно крупная компания, более 6000 человек – входим в 500 крупнейших налогоплательщиков страны. Сейчас в компании идет масштабный проект по переходу с УПП на «1С:Бухгалтерию предприятия».

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

Многие докладчики рассказывали сегодня про гибкие современные подходы – Agile, Scrum, Kanban. Но когда я сегодня про них слушала, я понимала, что в нашем проекте и в нашей компании такие методики не применимы. У нас все-таки работает классика, потому что, если мы будем настраивать спринты, мы никогда не придем к результату. Нам нужно все и сразу, а причесывать функциональность до бантиков и винтиков у нас можно до бесконечности – «бухгалтерию не остановить».

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

Если говорить о моем опыте составления ТЗ – за семь месяцев подготовки к проекту мы вместе с подрядчиком составили и согласовали около 900 ТЗ – это примерно по 150 техзаданий в месяц.

Сейчас все эти ТЗ реализовываются, и мы наступаем на грабли.

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

 

 

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

 

Какую роль эмпатия играет в составлении ТЗ

 

 

Эмпатия – психологический термин, имеющий определение:

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

Самый высокий уровень эмпатии можно выразить фразой:

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

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

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

 

 

 

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

 

Типы заказчиков

 

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

 

 

Первый тип – это дотошный детальный заказчик.


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

 

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

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

 

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


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

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

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

  • Но, с другой стороны, понять, что ему нужно – сложнее, потому что детали из такого заказчика вытащить невозможно.

 

Сбор требований

 

 

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

  • Из этих речей нужно вычленить проблемы, которые нужно решить. Чаще всего заказчик описывает ситуацию своими словами, из которых непонятен корень проблемы. Однажды мне звонила разгневанный кладовщик, долго кричала и жаловалась в трубку: «У меня не работает 1С, сделайте что-нибудь». Когда я попыталась выяснить, что именно нужно починить, женщина отвечала, что не знает, в чем проблема, но теперь она не может выдать документы водителю, а он из-за этого не может сходить в туалет. Пять минут я выслушивала не проблему, а то, что водитель не может сходить в туалет. Но это нужно было выслушать, чтобы потом остановиться и выяснить, какую проблему мы решаем: проблему водителя или проблему 1С?

  • Важно докопаться до истины и выявить проблему, а не слушать решение заказчика. Очень много среди заказчиков тех, кто знаком с программированием, знает 1С – они начинают раздавать свои советы и решения. Но нужно вычленить проблему. Если, как в анекдоте, клиент пришел к вам и просит отрубить ему голову, вы хотя бы на автомате поинтересуйтесь: какую задачу мы решаем, почему заказчик принял такое решение? Какие решения он еще рассматривал? Конечно, можно действовать исключительно по ТЗ и отрубить заказчику голову, но это будет некорректно, хотя финансово выгодно. Поэтому лучше докопаться до истины.

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

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

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

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

 

Проблемы при составлении ТЗ и способы их решения

 

Следующий момент при составлении ТЗ и сборе требований – это различные факапы, и как из них выйти. Какие бывают проблемы:

 

 

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

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

  • Разбор схемы заказчика. Часто при проведении совещаний с заказчиком начинают рисоваться схемы. На момент совещания вроде все всем ясно. Но когда совещание заканчивается, ты смотришь на листок со схемой и задаешься вопросом: о чем мы говорили, и как к этому пришли? Начинается раскручивание клубка: «Как мы к этому пришли? Как дошли до такой схемы?». Ситуация начинает прорисовываться и уточняться, потому что тут могут возникнуть новые нюансы и новые варианты решения.

  • Описание математики словами. Заказчик часто при постановке ТЗ начинает описывать математику словами. Например, предлагает считать KPI сотрудника по таким-то показателям: количеству заявок, помноженному на время выполнения. Идея хорошая, но сначала нужно посчитать все в Excel – какая формула получится, откуда брать цифры, каким будет результат? Чаще всего, тут выходят несостыковки. Как мы посчитаем KPI – будем складывать, умножать, делить? Возникают различные сложности. Поэтому не описываем математику словами, а обязательно садимся и просчитываем.

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

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

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

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

 

Подготовка решения для заказчика

 

 

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

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

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

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

 

Что должно быть в ТЗ

 

 

Понятно, что в ТЗ должна быть шапка, описание, но я скажу про неочевидные пункты.

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

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

  • Приводите изображение формы, если она меняется. Например, товароведы в наших магазинах осуществляют приемку товара в специальном АРМ. Они привыкли к определенным кнопкам, если мы какую-то кнопку переместим без предупреждения, это будет провал по всей сети. Поэтому перед тем, как что-то добавить или переместить, у нас идет предварительное обучение всех товароведов. Иначе у людей сломается мозг, и они оборвут техподдержку вопросами: «Что случилось?». Поэтому, если в рамках ТЗ меняется форма – обязательно ее рисуем.

  • Формы отчета – здесь то же самое, если добавляются новые показатели или аналитики, покажите в ТЗ, что было добавлено.

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

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

    Поэтому сейчас в описании способа реализации у нас осталась укрупненная форма логики того, что мы реализуем: с помощью каких регистров, объектов. Мы там не углубляемся в детали, не описываем все реквизиты на форме, не указываем тип всех измерений и ресурсов в формате Число(15,2). Потому что это бесполезно, здесь хочется оставить свободу действий разработчикам, чтобы они могли подобрать более удобный способ решения.

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

  • Контрольный пример – наличие самого контрольного примера или описание тестирования, как принять и проверить само ТЗ. Лучше, чтобы контрольных примеров было много – несколько вариантов правильного развития событий и несколько вариантов – с отклонениями.

 

Границы ТЗ

 

 

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

 

 

 

Вопросы

 

 

Нужно ли при составлении ТЗ на новую функциональность или систему описывать все вплоть до форм пользовательского интерфейса?

Я думаю, это нужно попытаться сделать, потому что проектирование интерфейсов на мобильном приложении мы всегда прорисовываем до деталей – это критично для линейного персонала. Там люди работают со средним специальным образованием, им однозначно нужно сделать удобный эргономичный интерфейс. Если это интерфейс к большой системе типа «Документооборот 1С-ЭДО», тут можно до бесконечности прорисовывать – поэтому здесь мы ориентируемся в зависимости от того, насколько заказчик адекватен, насколько ему нужно. Можно прописать один интерфейс примерно, а остальное будет аналогично. Но какой-то вариант интерфейса в ТЗ все равно нужно дать.
 

Самый частый тип заказчика – это тот, который думает, что знает, чего хочет. Но самый частый тип подрядчика – тот, кто знает, как надо делать, и не хочет слушать заказчика. Какие способы помогают разрешить этот диссонанс?

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

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

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

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

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

 

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

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

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

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

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

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. user1202150 11.06.22 08:22 Сейчас в теме
После слов "..идет масштабный проект по переходу с УПП на «1С:Бухгалтерию предприятия... " читать перестал. Перспектива понятна!
asutyagin; user1266323; +2 Ответить
2. Lapitskiy 1025 18.06.22 10:12 Сейчас в теме
(1) да, в статье же честно написано "Сейчас все эти ТЗ реализовываются, и мы наступаем на грабли.". Ну понятно, какой там ваш "канбан-барабан", у нас всё своё, легаси понимаешь, ничего это ваше новомодное неприменимо :)
Вообще, статья полезная тем, как не наступать на грабли .
Т.е. делайте все наоборот и будет счастье!
asutyagin; +1 Ответить
Оставьте свое сообщение

См. также

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

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

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

12.05.2022    718    raiml    2    

10 «заповедей» эксплуатации крупной информационной системы 1С

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

Крупные системы 1С давно уже перешагнули и десятки терабайт, и тысячи пользователей, но во многих случаях подход к эксплуатации таких систем остаётся не на должном уровне. Антон Дорошкевич на конференции Infostart Event 2021 Post-Apocalypse поделился более чем 10-ти летним опытом эксплуатации подобных систем, сведя его к 10 «заповедям», соблюдение которых сделает 1С надёжнее, а труд разработчика – благодарнее и благороднее.

11.07.2022    5304    a.doroshkevich    33    

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

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

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

23.06.2022    3010    ashtey    0    

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

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

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

16.06.2022    2481    1СERP    0    

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

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

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

12.05.2022    1055    raiml    4    

Открытое ПО и опыт его внедрения

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

Open Source. Открытое ПО и опыт его внедрения.

30.05.2022    2603    300_po_vstrechke    56    

1С-ники могут все, но они не могут все сразу. Рекомендации по внедрению Канбан-системы для проектов 1С

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

Директор по проектам Инфостарт Мария Темчина на конференции Infostart Event Post-Apocalypse делала большой доклад о внедрении Канбан-систем. В преддверии старта курсов Марии по управлению ИТ-проектами редакция Инфостарт решила поделиться с читателями докладом о работе ИТ-команд с Канбан. В статье вы узнаете, зачем внедрять такую систему работы, и как она помогает договариваться разработчикам и бизнесу.

22.04.2022    2039    MariaTemchina    1    

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

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

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

23.03.2022    1706    SerjoginaMaria    18    

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

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

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

30.06.2020    27896    biimmap    74    

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

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

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

16.02.2022    2641    chavalah    8    

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

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

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

08.02.2022    3135    SerjoginaMaria    37    

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

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

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

07.02.2022    4989    ashtey    20    

Обзор рынка автоматизации ввода данных с документов в систему учета Промо

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

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

07.11.2018    23749    Yana Petina    34    

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

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

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

02.02.2022    3403    denisgalimoff    3    

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

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

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

28.01.2022    2710    abir    20    

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

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

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

26.01.2022    1917    RayCon    0    

Иерархия IT-систем и выбор программного обеспечения для организации труда Промо

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

IT-системы плотно вошли в нашу жизнь. Мощные и сложные программные продукты используются в самых разных сферах. При этом многие забывают, что появились IT-системы не просто так, как программные продукты, которые нужно продавать и внедрять, а как инструменты организации и автоматизации труда.И очень важно помнить при выборе и внедрении IT-систем, что первичен здесь — труд, а не программное решение. Я не единожды сталкивался с тем, что люди выбирали программу просто потому, что: “она понравилась”. В результате появляются попытки “натянуть” процессное производство, например, работу молокозавода, на ERP-систему, предназначенную для дискретного производства (сборка изделий). 

23.03.2018    12680    raiml    16    

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

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

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

24.01.2022    4767    otkalo    0    

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

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

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

19.01.2022    5701    denisgalimoff    8    

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

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

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

25.11.2021    5960    VachKirp    7    

Проблемы внедрения 1С:ERP на крупном предприятии Промо

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

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

29.06.2017    37300    1СERP    79    

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

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

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

27.10.2021    4567    antonov_i    17    

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

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

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

18.10.2021    10991    papa_harlo    37    

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

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

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

15.10.2021    4192    Akcium    10    

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

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

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

28.06.2017    52101    raiml    37    

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

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

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

13.10.2021    1370    gntk    2    

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

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

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

16.08.2021    5179    ashtey    2    

Backend силами 1С. 4 кейса внедрений

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

На онлайн-митапе «Интеграционные решения в 1С» выступил руководитель цифровой трансформации в крупной производственной компании Николай Крылов. Он представил коллегам кейсы использования одного универсального инструмента для решения разных задач интеграции.

06.08.2021    3556    Nikola23    4    

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

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

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

28.06.2017    40063    raiml    10    

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

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

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

03.05.2021    5425    ashtey    13    

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

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

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

22.04.2021    11392    ashtey    2    

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

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

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

19.04.2021    23611    ashtey    6    

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

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

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

23.02.2017    29074    Gavrik    11    

Котлеты по-одесски, или с чем кушать IDEF0

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

В статье я расскажу, как же приготовить котлеты с помощью нотации IDEF0.

23.03.2021    4999    ashtey    5    

Пишем ТЗ через сценарии

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

От того, насколько одинаково понимают ТЗ заказчик и исполнитель, зависит успех проекта. Включение моделей на UML и BPMN в состав ТЗ помогает упростить взаимопонимание с заказчиком и обеспечить минимум доработок за счет полного покрытия всех процессов функциональностью системы. О том, как грамотно составить ТЗ и увязать требования заказчика с детализированными моделями, на митапе Saint Petersburg.Online рассказал Сергей Наумов.

05.03.2021    7802    SergeyN    6    

И снова про бизнес-процессы: живой опыт без теории

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

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

20.10.2020    2991    e_ivanova    7    

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

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

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

11.08.2016    38427    SamBadi    55    

Чего хочет разработчик от ТЗ? Примеры из практики

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

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

16.10.2020    8478    stas_ganiev    36    

Архитектор – строит, а что делает аналитик?

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

Как только вспоминаешь проект по внедрению, особенно тот, что средний и выше (а в уме мы держим, что это проект 1С), то тут же видишь кучу народа, и каждый что-то делает. И вот тут вопрос – кто и что делает на проекте?

14.10.2020    6773    ashtey    11    

Из хаоса в логику бизнес-процессов

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

Казалось бы, что о бизнес-процессах не поговорил только ленивый, и уж точно каждый второй проводил сравнительный анализ нотаций моделирования бизнес-процессов. Однако до сих пор данная тема остается запутанной, не структурированной и от этого актуальной. Как только начинаешь погружаться в BPMN, EPC, ARIS и прочее, то начинаешь понимать, что ничего уже не понимаешь. Поэтому данная статья будет или еще одним камешком в великой стене описания бизнес-процессов, или кирпичиком в новом фундаменте знаний по данной теме. Это уже покажет время.

06.10.2020    15068    ashtey    5    

Практические вопросы внедрения и развития автоматизации склада. Часть 2 Промо

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

Слайды к докладу на секции "Складские технологии" в малом зале на IEE-2013. Пример автоматизации склада по "бюджетному" варианту с использованием ТСД+RDP.

26.03.2015    32903    CheBurator    36    

Что делать, если с поддержкой 1С всё горит или несколько слов про ITSM…

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

Проекты - это, конечно, важно, с завершением проекта внедрения, жизнь прикладного решения, на самом деле, только начинается. И самое интересное еще только впереди… Не случайно в Agile все чаще говорят о “гибком управлении продуктом”, а вовсе не только “проектом”.

20.08.2020    3885    MariaTemchina    4    

Не спеша, эффективно и правильно – путь разработки. Часть 3. Практика

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

Черновой вариант книги Никиты Зайцева, a.k.a.WildHare. Разработкой на платформе 1С автор занимается с 1996-го года, специализация — большие и по-хорошему страшные системы. Квалификация “Эксперт”, несколько успешных проектов класса “сверхтяжелая”. Успешные проекты ЦКТП. Четыре года работал в самой “1С”, из них два с половиной архитектором и ведущим разработчиком облачной Технологии 1cFresh. Ну — и так далее. Не хвастовства ради, а понимания для. Текст написан не фантазером-теоретиком, а экспертом, у которого за плечами почти двадцать три года инженерной практики на больших проектах.

29.06.2020    14552    WildHare    33    

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

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

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

06.04.2015    38932    raiml    14    

Не спеша, эффективно и правильно – путь разработки. Часть 2. Теория

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

Черновой вариант книги Никиты Зайцева, a.k.a.WildHare. Разработкой на платформе 1С автор занимается с 1996-го года, специализация — большие и по-хорошему страшные системы. Квалификация “Эксперт”, несколько успешных проектов класса “сверхтяжелая”. Успешные проекты ЦКТП. Четыре года работал в самой “1С”, из них два с половиной архитектором и ведущим разработчиком облачной Технологии 1cFresh. Ну — и так далее. Не хвастовства ради, а понимания для. Текст написан не фантазером-теоретиком, а экспертом, у которого за плечами почти двадцать три года инженерной практики на больших проектах.

22.06.2020    15219    WildHare    25    

Находим взаимопонимание с заказчиками с применением Enterprise Architect

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

Enterprise Architect – мощное средство моделирования бизнес-процессов и информационных систем. Сергей Наумов на мастер-классе конференции Infostart Event 2019 Inception показал, как моделировать бизнес-процессы и составлять понятные заказчику документы при внедрении 1С-систем с помощью Enterprise Architect. Материалы мастер-класса будут полезны как разработчикам на платформе 1С, так и аналитикам, участвующим во внедрении.

19.06.2020    8877    SergeyN    0    

Не спеша, эффективно и правильно – путь разработки. Часть 1. Парадигма

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

Черновой вариант книги Никиты Зайцева, a.k.a.WildHare. Разработкой на платформе 1С автор занимается с 1996-го года, специализация — большие и по-хорошему страшные системы. Квалификация “Эксперт”, несколько успешных проектов класса “сверхтяжелая”. Успешные проекты ЦКТП. Четыре года работал в самой “1С”, из них два с половиной архитектором и ведущим разработчиком облачной Технологии 1cFresh. Ну — и так далее. Не хвастовства ради, а понимания для. Текст написан не фантазером-теоретиком, а экспертом, у которого за плечами почти двадцать три года инженерной практики на больших проектах.

15.06.2020    22438    WildHare    35    

Как построить микросервисную инфраструктуру

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

При росте информационных систем возникает потребность выноса определенной бизнес-логики в отдельное приложение для повышения отказоустойчивости и возможности одновременного использования этой функциональности в различных источниках. О том, как построить микросервисную инфраструктуру с использованием Apache Kafka в качестве шины данных, на конференции Infostart Event 2019 Inception рассказал разработчик группы компаний Автоград Дмитрий Маренин.

15.06.2020    15355    dmarenin    6