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

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С-ЭДО», тут можно до бесконечности прорисовывать – поэтому здесь мы ориентируемся в зависимости от того, насколько заказчик адекватен, насколько ему нужно. Можно прописать один интерфейс примерно, а остальное будет аналогично. Но какой-то вариант интерфейса в ТЗ все равно нужно дать.
 

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

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

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

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

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

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

 

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

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

 

30 мая - 1 июня 2024 года состоится конференция Анализ & Управление в ИТ-проектах, на которой прозвучит 130+ докладов.

Темы конференции:

  • Программная инженерия.
  • Инструментарий аналитика.
  • Решения 1С: архитектура, учет и кейсы автоматизации на 1С.
  • Управление проектом.
  • Управление продуктом.
  • Soft skills, управление командой проекта.

Конференция для аналитиков и руководителей проектов, а также других специалистов из мира 1С, которые занимаются системным и бизнес-анализом, работают с требованиями, управляют проектами и продуктами!

Подробнее о конференции.

 


См. также

Архитектурное ревью. Процесс разработки

Архитектура решений Бесплатно (free)

Рассмотрим применение архитектурной проверки задач в процессе разработки.

30.10.2023    3829    0    ivanov660    10    

29

Я - ЗУПер! Часть 4. Проблемы, возникающие при заключении договоров

Бизнес-анализ Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и Управление Персоналом 3.x Бесплатно (free)

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

07.08.2023    5119    0    biimmap    43    

57

Я - ЗУПер! Часть 3. Ошибки работодателей и соискателей. Плюсы специализации на одной предметной области

Бизнес-анализ Платформа 1С v8.3 1С:Зарплата и Управление Персоналом 3.x Бесплатно (free)

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

19.04.2023    4618    0    biimmap    37    

60

Я - ЗУПер! Часть 2. Классификация проектов и задач

Бизнес-анализ Платформа 1С v8.3 1С:Зарплата и Управление Персоналом 3.x Бесплатно (free)

В первой части рассмотрели компетенции специалиста в сфере ЗУП. В этой статье рассмотрим классификацию проектов и задач на проектах. Классификация построена на моём личном опыте длиною в 20 лет. На неё будем опираться в третьей части статьи.

13.04.2023    3447    0    biimmap    14    

41

Искусство отчета

Отчеты и дашборды Платформа 1С v8.3 Система компоновки данных Бесплатно (free)

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

26.02.2023    3376    0    DemetrKlim    38    

28

RPA для перехода с SAP на 1С

Бизнес-анализ Россия Бесплатно (free)

Зачем нужна роботизация при переходе с SAP на 1С. Как мигрировать с SAP с минимальными усилиями и даже без команд поддержки SAP.

09.01.2023    2246    0    comol    9    

7

Опыт работы «1С:ERP» в ландшафте Linux + PostgreSQL – 7 лет

Бизнес-анализ Платформа 1С v8.3 1С:ERP Управление предприятием 2 Россия Бесплатно (free)

В связи с обострением вопросов импортозамещения многие задумываются о переходе на системы, позволяющие заменить зарубежные аналоги, или уже его начали. Мы решили поделиться с вами 7-летним опытом установки и эксплуатации системы Linux + PostgreSQL + «1C» на 300 онлайн-пользователей.

16.12.2022    7559    0    1СERP    34    

67

Таблица для финансиста. Решение на стыке технологий

Бизнес-анализ Бесплатно (free)

Что будет, если взять от Excel простоту и легкость составления таблиц с формулами, а от базы данных – системность и возможность работы с общими справочниками? Сергей Тангатаров, руководитель направления бюджетирования и МСФО в Инфостарте, на конференции Infostart Event 2021 Post-Apocalypse рассказал о Табуле – решении «на стыке технологий», дающем возможности выполнять финансово-экономические проекты на новом уровне.

19.09.2022    3532    0    Serg_Tangatarov    0    

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