ТЗ для постановки ИС финансовой службы

[Александр_f]

Приветствую всех участников форума.

Имеется: горнодобывающее предприятие (численность - около 1000 чел, финансовая служба- 3 чел.).
В бухгалтерии - 1 чел., стоит 1С.
Предприятие входит в крупный холдинг, т.е. планирование и отчётность предназначены в первую очередь для управляющей компании. Но также хотелось бы видеть аналитику и для себя (в частности, себестоимость переделов).

Используются инструменты: Excel, Access (в качестве базы данных по платежам).

Подготовка плана и факта чрезвычайно трудоёмка (на мой взгляд): несколько экселевских файлов с перекрёстными ссылками, плюс необходимость ввода данных как в Access (для финансовой службы), так и для бухгалтерии (1С).
Например, при формировании типичного отчёта данные выгружаются из 1 С в экселевский файл, потом вставляются в другой файл, , потом готовится файл с изменёнными ссылками, потом ещё один и так далее... в общем, никак не XXI век.
Сразу говорю - дополнительного персонала никто набирать не станет, а вот установить систему (ту же 1С или другую, по нашему выбору) - это пожалуйста.

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

Скажите, пожалуйста, что должно содержать это ТЗ, как формулировать задачи для программеров и на что можно надеяться в результате?

[Елена И.]

я думаю, что нужно начать с конца

Сначала сами для себя подробно и максимально конкретно опишите - ЧТО Вы хотите иметь на выходе.

Т.е. какие формы отчетов, с какими данными.

Далее - "снимок" того, что есть сейчас: где источник этих данных, кто их генерирует и тд.

И потом вместе с техническим специалистом можно будет говорить о ТЗ.

[Евгений Пономарёв]

Есть специальный ГОСТ 34.602-89 в котором описаны требования к ТЗ на создание ИС.

[Александр_f]

Спасибо за советы, постараюсь ими воспользоваться.

В сущности, мы знаем, что хотим. Проблема - написать так, чтобы это понял It-специалист.

[AlexGoro]

Я думаю таких трудностей не возникнет. Главное - говорить, а не думать что программист все поймет сам.

[Green Hamster]

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

[ADikiy]

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

Тема для меня актуальная, как никогда. Многие эксперты схоятся во мнении что идеальным ТЗ для автоматизации является модель to be, в иделае написанная в нотации DFD.
Все это конечно здорово, но вот как она должна выглядеть?

Не считаю, что проблем с Итшниками не будет, потому что нужен общий язык для взаимодействия - в данном случае бизнес-процессы нотации DFD. но не все автоматизаторы знакомы с ним.

Лично я занимаюсь внедрением CRM-системы,модель to be готовы, но я не могу написать ТЗ. Наряду конечно же с техническими требованиями, есть ряд операционных к примеру как показать ИТшнику что после присовенения статуса клиенту - ПО автоматически расчитывает цену продукции, а после чего выдает вопрос - подготовить счет на оплату?

Буду признателен если поделитесь опытом

[Pavel Petrov]

тоже хотелось бы услышать о ТЗ от людей, которые уже писали ТЗ на постановку ИС или внедрение какой либо задачи в уже существущую ИС.
Какие разделы она должна в себя включать (Гост читал), охота обсудить этот вопрос с практиками, чувствую в моем ТЗ чего то не хватает. И еще как грамотно описать вопрос графика документооборота, на сколько подробно описывается (к примеру: Специалист Планово экономического отдела филиала заполняет прилагаемую форму, удостоверившись в правильности заполнения нажимает на кнопку в левом нижнем углу "Сохранить", данные должны быть заполнены в сроки указанные в разделе №3 "Сроки предоставления и заполнения отчетной информации". После чего вышестоящая организация ... " Прошу, кто уже сталкивался присоединиться к дискуссии и помочь разобраться.

[aquazer]

Структура документа описания требований - есть ГОСТы 34 и 19 серии, есть внутрикорпоративные стандарты (каждый крупный интегратор практически их имеет), есть стандарты производителей систем (от 1С до SAP). Чтобы понять, что лучше для Вас, нужно знать - для каких целей Вам ТЗ, как вы будете его использовать? вы его пишете для того, чтобы устроить тендер между поставщиками? или для внутренних целей: чтобы по нему работал свой ИТ отдел? или вы сторонний по отношению к автоматизируемому предприятию исполнитель и хотите написать ТЗ для них?

[Pavel Petrov]

Структура документа описания требований - есть ГОСТы 34 и 19 серии, есть внутрикорпоративные стандарты (каждый крупный интегратор практически их имеет), есть стандарты производителей систем (от 1С до SAP). Чтобы понять, что лучше для Вас, нужно знать - для каких целей Вам ТЗ, как вы будете его использовать? вы его пишете для того, чтобы устроить тендер между поставщиками? или для внутренних целей: чтобы по нему работал свой ИТ отдел? или вы сторонний по отношению к автоматизируемому предприятию исполнитель и хотите написать ТЗ для них?

Тз мне необходимо для того, чтобы сторонние программисты могли понять то, что мы хотим увидеть в конце выполнения задачи (результат на выходе), что нам нравится, что бы хотелось применить и как программа (система) должна работать и на основе всего этого создать программный продукт обеспечивающий и соответствующий заложенным в ТЗ требованиям.
Я конечно понимаю, что ТЗ по сути представляет собой подробную схему
"Кто-Кому-когда-что-в каком виде" но насколько подробно, какие моменты затрагивать, какие обычно забывают затронуть, последовательность и все остальное.
К примеру (можете каждый дополнить или оспорить содержание, будет интересно подискутировать)
1.
Содержание.
1.Общие положения.
2.Наименование работы.
3.Назначение и цели создания АИС.
4.Имя сайта/АИС/Раздела.
5.Название сайта/раздела.
6.Язык.
7.Характеристика объектов автоматизации.
8.Внешний вид окна интерфейса.
9.Расширенные функции формирования экранных форм.
10.Структура портала (какие тематические страницы будут расположены на портале).
11.Подразделы (структура).

12.Область пользователей .
13.График документооборота.
14.Сроки сдачи отчетности/ закрытия иформации/ завешивания документов.
15.Технологии (какие будут использованы технологии (языки программирования, специальные инструментарии).
16.Программное и аппаратное обеспечение.
17.Основные программные модули (форум, чат, обратная связь, вывод видов отчетных форм, списка филиалов и т.д.).
18.Вид хостинга (фирма, выделенная линия, отдельный сервер).
19.Этапы.
20.Сроки выполнения.
21.Требования к системе в целом.
21.1.Требования к структуре и функционированию системы.
21.2.Требования к производительности.
21.3.Требования к надёжности.
21.4.Требования к информационной безопасности.
21.5.Требования к стандартизации и унификации.
21.6.Требования к информационному обеспечению
21.7.Требования к техническому обеспечению
22.Требования к функциям системы
23.Состав и содержание работ по созданию системы.
24.Требования к документированию.
25.Порядок контроля и приемки АИС.
26.Источники разработки.
27.Порядок внесения изменений.

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

[Жигунов Александр]

Павел, а Вы, хотя бы год, хотя бы программистом, отработали?

Теперь по делу:

"ТЗ бывают 2-х видов, технические и функциональные.
Нормальный постановщик вместе с вами пишет функциональное ТЗ, потом сам техническое для программеров." - Не прибавить не отнять.

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

[Fedorov Alexey]

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

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

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

[aquazer]

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

Детализация зависит от того, привлекаете ли вы стороннюю команду на выполнение под фикс. договор или они будут на "повременке"
Для простоты рассмотрим ТЗ = перечень функциональных требований (без требований к сотрудникам, работающим в системе, требований к оборудованию, к быстродействию и т.п.).
Так вот, если это будет фикс, приготовьтесь к тому, что будет сделано то, что написано. При этом если какая-то часть подробно не будет описана будьте готовы "отдать" ее реализацию на усмотрение прогеров. Например, если в ТЗ напишете: "требуется обеспечить возможность регистрации инвойсов" и все - будьте готовы получить некий список с названием "Список инвойсов", где можно ввести новый элемент с любым составом полей на усмотрение прогера. Если опишете состав полей, то прогеры его повторят, но печатная форма будет опять-таки какой они захотят. Если приложите печатную форму, но не укажете, что в графу такую-то должно попадать то-то - будьте готовы получить форму, которая будет заполняться по правилам, придуманным прогерами. Если не выставите требований к внешнему виду диалогового окна для ввода нового инвойса - будьте готовы к тому, что на форме будет располагаться 20 закладок, причем кнопка "печать" будет на самой последней. Я утрирую конечно, но думаю понятно - все свои "критические" замечания нужно будет указать. Не думайте, что "очевидная" для вас вещь так же очевидна для прогера.
Другой подход - вы хотите на основе ТЗ подобрать наиболее подходящую систему из уже существующих. Тогда пишите "общие" формулировки, чтобы интеграторы могли соориентироваться в ваших требованиях и показать вам, как это выглядит в уже готовых системах. Если вас это устроит в целом - детальное ТЗ уже можно будет писать только на "несоответствия"

[Ромашина Диана]

Имеется: горнодобывающее предприятие (численность - около 1000 чел, финансовая служба- 3 чел.).
В бухгалтерии - 1 чел., стоит 1С.
Предприятие входит в крупный холдинг, т.е. планирование и отчётность предназначены в первую очередь для управляющей компании. Но также хотелось бы видеть аналитику и для себя (в частности, себестоимость переделов).

Используются инструменты: Excel, Access (в качестве базы данных по платежам).

Подготовка плана и факта чрезвычайно трудоёмка (на мой взгляд): несколько экселевских файлов с перекрёстными ссылками, плюс необходимость ввода данных как в Access (для финансовой службы), так и для бухгалтерии (1С).
Например, при формировании типичного отчёта данные выгружаются из 1 С в экселевский файл, потом вставляются в другой файл, , потом готовится файл с изменёнными ссылками, потом ещё один и так далее... в общем, никак не XXI век.
Сразу говорю - дополнительного персонала никто набирать не станет, а вот установить систему (ту же 1С или другую, по нашему выбору) - это пожалуйста.

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

Цель - именно написать техническое задание? Вообще-то есть готовые решения, например, одно я могу предложить. Оно рассчитано именно на замену экселей в управленческом учете, бюджетировании, управлении платежами, и дружит по загрузке факта с любыми конфигурациями 1С, где может вестись бухучет, в любом количестве (если несколько организаций ведутся в разных базах 1С). Внедряется от 2 (предприятие до 100 человек) до 6 (предприятие 100-1000 человек) месяцев без программиста, т.к. вся настройка загрузки факта и составления отчетов делается на пользовательском уровне.

[Лилия Исмаилова]

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

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

[vespol]

Добавлю свое ИМХО

Во-первых, согласен с мнением коллег, что если вы не специалист, то нормальное ТЗ вы не напишите, как бы ни старались. Они сами по себе разные. Это очень распространённая ошибка среди заказчиков, что им достаточно назначить специалиста, тот немного потренируется и составит ТЗ.

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

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

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

Оптимальный вариант - берется типовое решение, имеющееся на рынке и настраивается под конкретное предприятие.

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

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

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

[Ромашина Диана]

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

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

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

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

сейчас новые системы пишут или студенты, которым все нипочем, или, скажем прямо, те, кто не ориентируется в теме.

Интересно, откуда такая уверенная статистика? Только сертификация на 1С:Совместимо - по 3-5 программ ежедневно, согласно рассылке 1С. Это что, студенты, по-вашему? Наоборот, рынок программного обеспечения сейчас в стадии примерно такой, как рынок автомобилей во времена Генри Форда-старшего. Здесь можно сделать деньги, но ценой тяжелого труда.

[Ромашина Диана]

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

Это решение на платформе 1С 8.х. Сделано по принципу plug-and-play, как типовые конфигурации: только устанавливаем, и сразу можем получить первый результат. Настройка загрузки факта и всех вычислений делается на пользовательском уровне, но возможна и доработка программистом, т.к. это конфигурация под 1С. Более подробно предлагаю ответить лично. Также лично могу дать рекомендателей (они далеко не все соглашаются, чтобы их контакты выкладывались на сайт, т.к. речь идет об управленческом - внутреннем - учете).

[vespol]

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

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

Интересно, откуда такая уверенная статистика? Только сертификация на 1С:Совместимо - по 3-5 программ ежедневно, согласно рассылке 1С. Это что, студенты, по-вашему? Наоборот, рынок программного обеспечения сейчас в стадии примерно такой, как рынок автомобилей во времена Генри Форда-старшего. Здесь можно сделать деньги, но ценой тяжелого труда.

Где уж нам уж

Только в своем рекламном запале вы не замечаете, что полностью подтверждаете сказанное мною

Напомню, о чем шла речь: Оптимальный вариант - берется типовое решение, имеющееся на рынке и настраивается под конкретное предприятие.

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

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

Отсюда понятны и парадоксы, что "лучше работают те программы, которые более распространены"

И ваш следующий пост еще раз подтверждает сказанное, где вы предлагаете решение на платформе 1С 8, плюс доработки программиста

Так что, ничто не ново под Луной и изобретать в очередной раз велосипед никому не возбраняется

[Ромашина Диана]

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

Всевозможные запалы и приравнивание моих слов тем или этим "парадигмам" оставляю на Вашей совести, а по делу вот что. 1С 8.х - это ПЛАТФОРМА. Это не то же самое, что типовые конфигурации. Это система программирования, т.е. инструмент, так же, как С++ или Delphi, и я на ней работаю только потому, что она более распространена, отсюда рынок сбыта больше. Типовые конфигурации - это прикладные программы, сделанные на платформе 1С. Те программы, которые сертифицируются на 1С совместимо, - это, как правило, не доработки, а самостоятельные разработки, которые дописыванием типовых конфигураций не являются (некоторые из них имеют базовую конфигурацию - одну из типовых, но это меньшинство).

Т.е. можно, конечно, утверждать, что все программы, написанные под процессор Intel, - доработки DOS. А компьютер - доработка каменного топора. Тогда человек - это, очевидно, доработка амебы...

[Кручинецкий Сергей]

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

Если тема ещё актуальна. Методика работы бизнес-аналитика - на этом сайте в статье по ссылке