Показано с 1 по 21 из 21
-
13.03.2007, 18:26 #1
ТЗ для постановки ИС финансовой службы
Приветствую всех участников форума.
Имеется: горнодобывающее предприятие (численность - около 1000 чел, финансовая служба- 3 чел.).
В бухгалтерии - 1 чел., стоит 1С.
Предприятие входит в крупный холдинг, т.е. планирование и отчётность предназначены в первую очередь для управляющей компании. Но также хотелось бы видеть аналитику и для себя (в частности, себестоимость переделов).
Используются инструменты: Excel, Access (в качестве базы данных по платежам).
Подготовка плана и факта чрезвычайно трудоёмка (на мой взгляд): несколько экселевских файлов с перекрёстными ссылками, плюс необходимость ввода данных как в Access (для финансовой службы), так и для бухгалтерии (1С).
Например, при формировании типичного отчёта данные выгружаются из 1 С в экселевский файл, потом вставляются в другой файл, , потом готовится файл с изменёнными ссылками, потом ещё один и так далее... в общем, никак не XXI век.
Сразу говорю - дополнительного персонала никто набирать не станет, а вот установить систему (ту же 1С или другую, по нашему выбору) - это пожалуйста.
Единственная проблема - грамотно написать техническое задание.
Скажите, пожалуйста, что должно содержать это ТЗ, как формулировать задачи для программеров и на что можно надеяться в результате?
-
14.03.2007, 10:27 #2
- Регистрация
- 28.11.2005
- Сообщений
- 1,326
я думаю, что нужно начать с конца
Сначала сами для себя подробно и максимально конкретно опишите - ЧТО Вы хотите иметь на выходе.
Т.е. какие формы отчетов, с какими данными.
Далее - "снимок" того, что есть сейчас: где источник этих данных, кто их генерирует и тд.
И потом вместе с техническим специалистом можно будет говорить о ТЗ.
-
14.03.2007, 19:25 #3
Есть специальный ГОСТ 34.602-89 в котором описаны требования к ТЗ на создание ИС.
-
16.03.2007, 13:03 #4
ТЗ для ИС
Спасибо за советы, постараюсь ими воспользоваться.
В сущности, мы знаем, что хотим. Проблема - написать так, чтобы это понял It-специалист.
-
16.03.2007, 17:25 #5
- Регистрация
- 30.11.2006
- Сообщений
- 1
Я думаю таких трудностей не возникнет. Главное - говорить, а не думать что программист все поймет сам.
-
27.06.2007, 15:23 #6
- Регистрация
- 20.06.2007
- Сообщений
- 22
ТЗ бывают 2-х видов, технические и функциональные.
Нормальный постановщик вместе с вами пишет функциональное ТЗ, потом сам техническое для программеров.
-
13.12.2007, 13:50 #7Сообщение от Green Hamster
Все это конечно здорово, но вот как она должна выглядеть?
Не считаю, что проблем с Итшниками не будет, потому что нужен общий язык для взаимодействия - в данном случае бизнес-процессы нотации DFD. но не все автоматизаторы знакомы с ним.
Лично я занимаюсь внедрением CRM-системы,модель to be готовы, но я не могу написать ТЗ. Наряду конечно же с техническими требованиями, есть ряд операционных к примеру как показать ИТшнику что после присовенения статуса клиенту - ПО автоматически расчитывает цену продукции, а после чего выдает вопрос - подготовить счет на оплату?
Буду признателен если поделитесь опытом
-
07.05.2008, 19:03 #8
- Регистрация
- 07.08.2006
- Сообщений
- 82
тоже хотелось бы услышать о ТЗ от людей, которые уже писали ТЗ на постановку ИС или внедрение какой либо задачи в уже существущую ИС.
Какие разделы она должна в себя включать (Гост читал), охота обсудить этот вопрос с практиками, чувствую в моем ТЗ чего то не хватает. И еще как грамотно описать вопрос графика документооборота, на сколько подробно описывается (к примеру: Специалист Планово экономического отдела филиала заполняет прилагаемую форму, удостоверившись в правильности заполнения нажимает на кнопку в левом нижнем углу "Сохранить", данные должны быть заполнены в сроки указанные в разделе №3 "Сроки предоставления и заполнения отчетной информации". После чего вышестоящая организация ... " Прошу, кто уже сталкивался присоединиться к дискуссии и помочь разобраться.
-
10.05.2008, 02:34 #9
- Регистрация
- 16.10.2006
- Сообщений
- 3
Структура документа описания требований - есть ГОСТы 34 и 19 серии, есть внутрикорпоративные стандарты (каждый крупный интегратор практически их имеет), есть стандарты производителей систем (от 1С до SAP). Чтобы понять, что лучше для Вас, нужно знать - для каких целей Вам ТЗ, как вы будете его использовать? вы его пишете для того, чтобы устроить тендер между поставщиками? или для внутренних целей: чтобы по нему работал свой ИТ отдел? или вы сторонний по отношению к автоматизируемому предприятию исполнитель и хотите написать ТЗ для них?
-
12.05.2008, 18:54 #10
- Регистрация
- 07.08.2006
- Сообщений
- 82
Сообщение от aquazer
Я конечно понимаю, что ТЗ по сути представляет собой подробную схему
"Кто-Кому-когда-что-в каком виде" но насколько подробно, какие моменты затрагивать, какие обычно забывают затронуть, последовательность и все остальное.
К примеру (можете каждый дополнить или оспорить содержание, будет интересно подискутировать)
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.Порядок внесения изменений.
Если что не так или что-то важное упустил прошу меня дополнять, одна голова хорошо, а совет и здравая мысль все равно не помешают.
-
13.05.2008, 14:23 #11
- Регистрация
- 03.05.2008
- Сообщений
- 6
Павел, а Вы, хотя бы год, хотя бы программистом, отработали?
Теперь по делу:
"ТЗ бывают 2-х видов, технические и функциональные.
Нормальный постановщик вместе с вами пишет функциональное ТЗ, потом сам техническое для программеров." - Не прибавить не отнять.
Все зависит от ваших программистов. Условно их можно поделить на
Программистов и кодеров. Программисты разрабатывает систему вместе с вами. Программисты продумывают необходимые реквизиты, систему поиска, систему внесения изменений, корректировки, технические регламентные работы, которые будут необходимы системе и т.д. и т.п.
С кодерами все сложнее, все функции прогеров берете Вы на себя.
Если Вы не отработали хотя бы 3 года, хотя бы программистом - тз Вы не поставите никогда. Если Вы не программист - сосредоточтесь на функциональном тз и ищите себе в подмогу программиста. Обязательно.
-
14.05.2008, 10:45 #12
- Регистрация
- 13.05.2008
- Сообщений
- 1
хорошее ТЗ в первую очередь состоит из грамотного описания задания в первую очередь это - схема документопотока подсистемы(лучше всего при этом использовать форматы IDEF0 и DFD), где каждая из вложенных подсистем описывается детально:
-формы
-данные в т.ч. входные, выходные и промежуточные
-хранимые таблицы
-виртуальные(рассчитываемые) таблицы
-ограничения по правам
-ограничения по возможностям
-документы
-отчеты или данные для отчетов(т.к. есть отчеты которые могут строиться по нескольким подсистемам)
так же необходимо в ТЗ указывать назначение каждой из подсистем, в том числе и самую главную
функциональное же задание состоит из функционала, который вы хотите получать от этой системы и каждой подсистем, отчетов, данных которыми вы обладаете и что нужно с ними делать, как обрабатывать и т.п.
ТЗ написать, если не имеете на руках уже пару готовых грамотных решений вы самостоятельно написать не сможете - пишите функционал, этого для хорошего специалиста будет вполне достаточно, чтобы потом вместе с Вами разработать грамотносформулированное задание для постановки задач разработчикам
-
16.05.2008, 21:58 #13
- Регистрация
- 16.10.2006
- Сообщений
- 3
Сообщение от Pavel Petrov
Для простоты рассмотрим ТЗ = перечень функциональных требований (без требований к сотрудникам, работающим в системе, требований к оборудованию, к быстродействию и т.п.).
Так вот, если это будет фикс, приготовьтесь к тому, что будет сделано то, что написано. При этом если какая-то часть подробно не будет описана будьте готовы "отдать" ее реализацию на усмотрение прогеров. Например, если в ТЗ напишете: "требуется обеспечить возможность регистрации инвойсов" и все - будьте готовы получить некий список с названием "Список инвойсов", где можно ввести новый элемент с любым составом полей на усмотрение прогера. Если опишете состав полей, то прогеры его повторят, но печатная форма будет опять-таки какой они захотят. Если приложите печатную форму, но не укажете, что в графу такую-то должно попадать то-то - будьте готовы получить форму, которая будет заполняться по правилам, придуманным прогерами. Если не выставите требований к внешнему виду диалогового окна для ввода нового инвойса - будьте готовы к тому, что на форме будет располагаться 20 закладок, причем кнопка "печать" будет на самой последней. Я утрирую конечно, но думаю понятно - все свои "критические" замечания нужно будет указать. Не думайте, что "очевидная" для вас вещь так же очевидна для прогера.
Другой подход - вы хотите на основе ТЗ подобрать наиболее подходящую систему из уже существующих. Тогда пишите "общие" формулировки, чтобы интеграторы могли соориентироваться в ваших требованиях и показать вам, как это выглядит в уже готовых системах. Если вас это устроит в целом - детальное ТЗ уже можно будет писать только на "несоответствия"
-
15.10.2008, 07:48 #14
- Регистрация
- 08.06.2008
- Сообщений
- 53
Сообщение от Александр_f
-
15.10.2008, 15:11 #15
- Регистрация
- 08.10.2008
- Сообщений
- 3
Вообще-то есть готовые решения, например, одно я могу предложить. Оно рассчитано именно на замену экселей в управленческом учете, бюджетировании, управлении платежами, и дружит по загрузке факта с любыми конфигурациями 1С
-
16.10.2008, 03:00 #16
- Регистрация
- 29.06.2007
- Сообщений
- 243
Добавлю свое ИМХО
Во-первых, согласен с мнением коллег, что если вы не специалист, то нормальное ТЗ вы не напишите, как бы ни старались. Они сами по себе разные. Это очень распространённая ошибка среди заказчиков, что им достаточно назначить специалиста, тот немного потренируется и составит ТЗ.
Поэтому действительно, не надо тратить лишнее время и силы, найдите хорошего программиста, лучше не простого, а системного аналитика, и просто расскажите ему, что нужно, остальное он сам сделает и растолкует своим коллегам-кодерам.
Идеальный вариант, конечно, найти хорошего бизнес-аналитика, у которого эта работа входит в прямые обязанности.
Следующая проблема, которая сквозит здесь в обсуждении, что народ похоже хочет написать свою систему. Это уже в прошлом, сейчас новые системы пишут или студенты, которым все нипочем, или, скажем прямо, те, кто не ориентируется в теме.
Оптимальный вариант - берется типовое решение, имеющееся на рынке и настраивается под конкретное предприятие.
И здесь же следующий важный момент - не надо изощряться и придумывать какие-то функции сугубо под отдельных пользователей. Все уже известно, все уже достаточно типизировано. Есть, конечно, какие-то исключения, но это довольно редко. У всех есть склад, накладные, кассы, финансы, филиалы, взаиморасчеты и т.д., и т.п.
И последнее, точно также на напрягайтесь при выборе системы. Как правильно заметил в каком-то форуме один из наших коллег, основной аргумент при выборе - это финансовые возможности.
Для иллюстрации вспомните, как покупаются машины. Никто ведь не будет требовать машину с возможностями, которые в несколько раз превышают размер кошелька покупателя. Покупают то, что могут себе позволить. То же и с автоматизированными системами. Тем более, что сейчас они становятся все больше и больше похожими друг на друга, те же модули, те же функции, сервисы.
-
16.10.2008, 10:26 #17
- Регистрация
- 08.06.2008
- Сообщений
- 53
Сообщение от vespol
Горький опыт в том, что у программ гораздо больше функций, которые должны складываться в единую систему, быть удобными в использовании, должно быть легко обучить пользователей, и программа неизбежно годами дорабатывается, так как ньюансов миллион. Поэтому, как ни парадоксально, лучше работают те программы, которые более распространены, т.к. больше народу их тестирует и сообщает свое возмущенное мнение. Не зря же Билл Гейтс сказал: "Ваш самый лучший источник знаний - ваши самые недовольные клиенты". Мой опыт внедруния всяческих программ: и самописных, и дешевых, и дорогих меня убедил во мнении, что оптимальный результат по цене/результатам внедрения дает набор очень распространенных простых программ, примененных в той области, для которой они предназначены, и связанных между собой автоматической передачей данных.
Сообщение от vespol
-
16.10.2008, 10:40 #18
- Регистрация
- 08.06.2008
- Сообщений
- 53
Сообщение от Лилия Исмаилова
-
16.10.2008, 12:59 #19
- Регистрация
- 29.06.2007
- Сообщений
- 243
Сообщение от Ромашина Диана
Только в своем рекламном запале вы не замечаете, что полностью подтверждаете сказанное мною
Напомню, о чем шла речь: Оптимальный вариант - берется типовое решение, имеющееся на рынке и настраивается под конкретное предприятие.
Я специально выше сохранил такую большую вашу цитату, чтобы показать, что "горький опыт" может быть слаще, если правильно смотреть на вещи.
Все то, что вы сказали полностью укладывается в эту парадигму, и те "3-5 программ ежедневно по сертификации на 1С", это и есть настройки типового решения, варианты базового типового решения
Отсюда понятны и парадоксы, что "лучше работают те программы, которые более распространены"
И ваш следующий пост еще раз подтверждает сказанное, где вы предлагаете решение на платформе 1С 8, плюс доработки программиста
Так что, ничто не ново под Луной и изобретать в очередной раз велосипед никому не возбраняетсяПоследний раз редактировалось vespol; 16.10.2008 в 13:08.
-
16.10.2008, 15:12 #20
- Регистрация
- 08.06.2008
- Сообщений
- 53
Сообщение от vespol
Т.е. можно, конечно, утверждать, что все программы, написанные под процессор Intel, - доработки DOS. А компьютер - доработка каменного топора. Тогда человек - это, очевидно, доработка амебы...
-
01.04.2009, 10:34 #21Сообщение от vespol
Последний раз редактировалось Иринa; 01.04.2009 в 13:07.