76

Примеры / Re: Задачи на построение диаграммы вариантов использования

« : 09 Января 2008, 16:35:50 »

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

Тексты-то тоже разные для разных уровней. ИМХО существует задача превращения представлений "бизнес-уровня" в представления уровня "компьютерной системы". Если система создается коллективом с разделением ролей на разработчиков и бизнес-аналитиков, именно эта проблема может быть главным камнем преткновения. Использование системы нотаций, в которой свободно ориентируются и те и другие, частично облегчает эту задачу. Но все равно остается проблема доведения описания бизнеса до уровня, на котором дальнейшая проектная работа должны "подхватываться" разработчиками и проделанная бизнес-аналитиком работа должна реально облегчать работу разработчикам. И "сращивание" описаний разных уровней, соответствующих разным практикам, разным мышлениям, разным предметным специализациям (Заказчика и разработчиков) - это на самом деле "великое чудо маниту" для каждого конкретного проекта. Мне в этом плане очень понравилась контекстная диаграмма Boatman. Правда для больших проектов такая "многоуровневая диаграмма" иногда получается очень громоздкой, приходится "разводить" представления для разных уровней по разным диаграммам. Тогда могут возникать проблемы на стыке двух уровней.

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

Меня раздражает то  факт, что все трактуют правила построения по-разному. Но они то должны быть одни

ДВИ нужно обсуждать с Заказчиком если мы собираемся "вынимать" из него экспертные знания по его предметной области. Если же он экспертом в данной области не является (а он им не может являться если не обладает хоть в какой-то мере формализованными представления о предметной области) то надо брать экспертизу со стороны или вообще не делать систему, а купить ему готовое решение с инструкцией по нажатию нужных кнопок. Если же Заказчик хоть чуть-чуть эксперт, то схема с эллипсами и человечками ИМХО - в самый раз для начала разговора.   Надо только начинать разговор не со схемы а с обсуждения его конкретной работы типа: " вот Вы берете этот документ так? несете его директору так? ну, хорошо, бухгалтеру так? вот. Я на картинке это нарисовал, вот Вы, вот бухгалтер, так правильно да?". И дальше в таком же стиле: "за маму, за папу..." это мучительно, но неизбежно....

77

Примеры / Re: Задачи на построение диаграммы вариантов использования

« : 09 Января 2008, 16:00:36 »

...Меня до сих пор волнует вопрос, а как отображать на таких ДВИ факт участия того же клиента или водителя. Читая книги (в первую очередь создателей UML) я однозначно читаю, что клиент или водитель показываться не должен, ну нет у них варианта использования нашей системы автоматизации, хотя он и участник.

Для целей именно использования системы, возможно, водитель и клиент не должны показываться на «системном уровне» если под «системой» понимать исключительно компьютер. Если же под системой понимать всю компанию такси, элементы которой образует системно организованный бизнес, то без этих лиц не обойтись. В конце концов программная система делается для решения задач бизнес-системы.
В частности, в постановке задаче нигде не сказано, что система должна учитывать интересы клиента и в этом смысле она ничем не отличается от постановки задачи перевозки грузов, решение о транспортировке которых принимает сам диспетчер. В жизни же (на бизнес уровне) приходится учитывать, что не только компания-перевозчик выставляет рейтинги клиентам, но и клиенты выставляют рейтинги компаниям. В городах с населением несколько десятков тысяч жителей, как правило, существует не одна компания такси и нужно выживать в конкурентной борьбе. Поэтому система должна «затачиваться» не только под диспетчера – «экспедитора живого товара», но и под интересы живых пассажиров, для которых, например, может быть критично, насколько оперативно подается машина и тогда нужно выставлять рейтинги не только клиентам, но и водителям, вести статистику времени выполнения заказов, жалоб клиентов и отказываться от услуг водителей с чересчур медленными и часто ломающимися машинами. Задача качественного обслуживания неизбежно потребует учета характеристик заказа клиента – срочности, междугородней поездки, которая может потребовать дополнительных приготовлений от водителя, и пр.  Эти характеристики и свойства могут быть правильно поняты только из бизнес-уровня, соответствующего рамке «Служба такси» на контекстной диаграмме Boatman.
Аналогично с водителем – у него есть очень конкретный вариант использования на бизнес уровне: как минимум оплатить услуги диспетчера.

...К примеру система учета прохождения исполнительного листа в неком госучреждении при судебном органе. Студент показывает в бизнес-контексте как и по каким инстанциями проходит исполнительный лист. Далее изображает системные процессы ИС учета, в которой например налоговая инспекция получает отчет о сумме исполнительного листа. Я спрашиваю, что налоговая инспекция имеет доступ в систему и получает возможность простмотра и получения таких отчетов. Оказывается нет, просто пользователь системы готовит такой отчет для налоговой инспекции и отправляет установленным порядком в бумажном виде или по email. Понятны мои логические блуждания?

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

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

Вполне вероятно, такая формулировка тоже не очень корректна.

Shur, может быть Вы поможете развеять мои заблуждения?

Может быть стоит предлагать студентам строить ДВИ, соответствующие различным уровням описания системы (уровень бизнеса и уровень «системы»)?
А высший пилотаж – это если они еще и покажут как эти уровни ДВИ взаимодействут между собой (типа  контекстной диаграммы Boatman).

78

Примеры / Re: Задачи на построение диаграммы вариантов использования

« : 09 Января 2008, 11:38:07 »

...Я все больше убеждаюсь, что ДВИ малозначима.

ИМХО ДВИ малозначима для описания алгоритмов в виде, достаточно подробном и удобном для кодирования (выше Boatman также указывал на малую информативность ДВИ). Не случайно в средах разработки, допускающих автоматическую генерацию кода по диаграммам, ДВИ и диаграмма деятельности никак не используются для генерации кода.
Но ДВИ, например, может быть очень важной отправной точкой для общения с Заказчиком. Этот момент, к сожалению, в обсуждениях на форуме не всегда ярко проявляется именно вследствие высокого профессионализма участников обсуждения, а также, возможно, малого количества "практикующих Заказчиков" среди обсуждающих. Но даже в этом обсуждении консенсус по поводу общего представления о системе был достигнут не сразу: Денис указал на то, что заказ к клиента принимает не система, а диспетчер. А контекстная диаграмма Воаtman позволила сразу наглядно представить и рамки бизнес-уровня и уровень системы.
1. При общении с заказчиком, который не испытывает потребности в явном описании/проговаривании логики своей работы, ДВИ, как правило, весьма полезна. Бывает, что нужно сначала договориться - мы для целей создания системы считаем, что земля круглая или достаточно будет считать, что она плоская и даже не пытаться развеивать заблуждения закзачика о том, что она стоит на четырех слонах .
В этом смысле ДВИ как минимум отражает топологию взаимодействия действующих/заинтересованных лиц. А топология может оказаться разной для разных способов организации бизнеса (чем он сложнее, тем, как правило, больше возможных вариантов организации взаимодействия).
2. Более того, изображение вариантов использования в виде эллипсов без детализации как бы инкапсулирует всю сложность внутреннего устройства варианта с точки зрения его использования действующим лицом, которое, возможно не понимает (и не должно) понимать всей сложности процессов, которые этот ВИ реализуют. Ведь если воспользоваться параллелями с инженерными дисциплинами, на которые указывал выше Boatman, автомобили-иномарки удобнее в использовании, чем отечественные, хоти и устроены сложнее с точки зрения изготовления и ремонта. Конструктор знаменитого автомата Калашников говорил, что он всю жизнь руководствовался афоризмом одного известного богослова: "Все нужное просто, всё сложное - не нужно...". Жизнь правда требует уточнения: системы должны быть не сколько простыми в изготовлении, как АКМ или Запорожец, сколько просты в использовании. И простота, понятность вариантов использования по идее являются залогом выского уровня юзабилити.

79

Примеры / Re: Компания по продаже полов, ламината, в большом количестве но в розницу

« : 05 Января 2008, 16:42:06 »

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

2. ....сам продукт это только линк между описанием продукта в каталоге и емкостью....

1. Не очень понятно все-таки, у Вас продукт - это "уникальный объект" (1), относящийся к master data, основным данным Вашей системы или только "связь/линк" (2) ?
Каталог - это и есть продукт (запись/записи о конкретном продукте, поставляемом поставщиком)?
Есть несколько поставщиков и у каждого свой каталог? 
Если Продукт только связывает пункт каталога (описание конкретного товара/продукта в каталоге) и емкостью (количеством товара на складе?) то на схеме это никак не показано.
По Вашей схеме Продукт - это скорее некий внутренний каталог компании, который используется только при формировании заказа (но не при доставке клиенту), при этом он никак не связан программно с Каталогом (поставщика?).
2. Не очень понятно, почему к процедуре работы с заказом на схеме Conceptual data model  отнесены только оферта и фактура? Если ставится цель автоматизировать весь конвейер от заказа до доставки продукта к клиенту, представляется логичным использовать Заказ в качестве одной из ключевых сущностей Вашей системы, которая используется во всех процессах от создания заказа клиента до его выполнения (доставки заказа). Ведь пользователи Вашей системы не меняют свойства продукта, при работе системы меняются только свойства/параметры Заказа на этот продукт. В частности оферта и фактура содержат данные о Заказе на разных стадиях его жизненного цикла (lifetime). Поэтому это скорее разные состояния одного Заказа. Если важно, чтобы оферту и фактуру можно было бы распечатывать в виде бумажных документов и есть конкретные требования к информации, которая должна в этих бумажных документах содержаться, то это другая задача. Не стоит бумажные документы сразу рассматривать в качестве master data Вашей системы.
3. Предлагаю Вам изобразить на Conceptual data model только сущности и связи между  ними (ER схему или диаграмму классов) и не пытаться показывать на этой диаграмме разные состояния одной сущности.

80

Примеры / Re: Компания по продаже полов, ламината, в большом количестве но в розницу

« : 03 Января 2008, 17:42:29 »

Хорошо бы уточнить цели:
1. Кто хочет быстрее работать? Начальник или сами продавщицы?
1.1 Действительно ли производительность компании зависит от скорости обработки информации? Или просто есть желание сделать все "как у взрослых" ?
1.2 По крайней мере, важно обеспечить доброжелательное отношение к Вашей программе не только со стороны начальника, но и пользователей. Для этого важно учесть их пожелания, сделать так, чтобы Ваша программа реально  делал бы их работы более простой и легкой.

2. Описанный Вами функционал включает по крайней мере:
2.1 автоматизацию закупок товара у Ваших поставщиков - пока в основном на уровне ведения каталога товаров. Вы что-то написали про то, что он настраивается под сотрудников. Т.е. разные сотрудники по разному используют содержащуюся в нем информацию? 
2.1.1 Есть специализация среди продавцов по виду товара или поставщику? Или
2.1.2 есть сотрудник, который учитывает поступающий от поставщиков товар, а остальным доступна только справочная информация для продажи клиентам?

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

2.3 автоматизацию складского учета ("хранилище", в России это обычно называется склад, а хранилище - это где хранится информация о том, что хранится на складе:) ). А кладовщик у Вас уже есть? Кто регистрирует получение товара на склад и отгрузку потребителю? Кто отвечает за то, что товар "просто" не взяли со склада?

2.4 автоматизацию учета рабочего времени для расчета оплаты или нормирования труда (payroll).

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

2.6. автоматизацию бухгалтерского учета (general ledger). Даже если он достаточно простой, все равно его надо делать (или купить что-нибудь готовое и грузить в него информацию из других модулей).

Вы хорошо представляете себе объем работы (в человеко-часах), которую Вам предстоит выполнить?

2. Вы писали, что в настоящий момент уже есть программы, которые используют продавщицы. Сколько их (программ), какая информация в них хранится (модель данных, - надо описать, даже если это Excel)? Чтобы внедрение новой системы было как можно меньшим потрясением для компании, важно, чтобы в новой программе можно было делать всё, что можно было делать в старой. Должна быть предусмотрена быстрая миграция данных (перегрузка) из старой системы в новую. А если в системе используется долгоживущая информация, то чем больше новая модель данных будет отличаться от старой, тем больше будет хлопот при внедрении системы.

81

Бизнес-анализ и Целеполагание / Re: Обещанная статья про целеполагание

« : 28 Декабря 2007, 13:39:08 »

Проблемы, описанные в статье характерны не только для ИТ, но и для других видов отечественного бизнеса. Тяжело приживается практика расчета смет в строительстве. Ведь по большому счету этой практике лет 16 только, раньше соотносить натуральные объемы работ с их денежным выражением не было настолько актуально на "микроуровне", уровне отдельного предприятия. Поэтому специалисты, которые этим занимаются, рисуют очень похожую картину . Даже в ИТ-компаниях мысли, близкие по содержанию к высказанным в данном статье, высказывают маркетологи, HR, но при этом они-то говорят о своем деле!
В каком-то смысле можно говорить о недостаточной культуре проектного мышления в широком смысле этого слова: т.е. очень распространено представление о том, что
1. сложные вещи можно делать "просто", решая возникающие проблемы по ходу их возникновения,
2. а некое представление о том, что именно должно получиться в результате и как именно оно будет делаться (проект) вроде бы и не нужно.
Причем драматизм ситуации для ИТ заключается в том, что "промышленным образом" могут автоматизироваться достаточно "регулярные практики": типовые ИТ-решения для типовых видов бизнеса. В какой мере можно считать бизнес заказчика типовым, в той мере можно его успешно автоматизировать типовым ИТ-решением, а также реализуя решение типовым способом. В каком-то смысле можно говорить о том, что существующая культура бизнеса, недостаточное развитие "регулярных бизнес-практик" сдерживает развитие ИТ.   

82

Управление Проектом / Re: Руководитель проекта, как им стать?

« : 24 Декабря 2007, 15:48:58 »

Дмитрий, попробуйте оценить привлекательность для Вас специализации системного аналитика или архитектора систем.
ИМХО:
1. для PM очень важно добиваться выполнения работ разработчиками системы, минимально стесняя их в принятии решении о способах и конкретных вариантах реализации. Конечно рамки сроков и стоимости всегда будут вынуждать вас ставить ограничения на конкретные варианты, но пристрастие к технологическим и архитетктурным аспектам реализации может послужить помехой и даже стать причиной конфликтов с разработчками.
2. существенной частью работы PM являются навыки "разруливания" конфликтных ситуаций с Заказчиком и даже внутри своей команды. Удовлетворение клиента является первоочередной задачей и бывает тяжело соглашаться на не очень технологически совершенные решения, но в силу различных обстоятельств Заказчика иногда приходится на это идти. Поэтому если для Вас совершенство программных решения очень Важно, Вам может оказаться (психологически прежде всего) тяжело искать приемлемые бизнес-решения...

83

Системный Анализ и Требования / Re: Писать ли статью про ТЗ по ГОСТ 34.602?

« : 13 Декабря 2007, 18:00:38 »

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

1. Я согласен, что автоматизация взаимодействия может менять содержание бизнес-процессов, но может и не изменять. И то и другое может иметь место и зависит от того из-за чего нам пришлось задаваться таким вопросом. Для меня представляется значимым, что, например, бухгалтерский учет возник существенно раньше, чем возникли системы, его автоматизирующие. Соответственно, первый автоматизатор бухгалтерского учета не имел значимых прототипов, которые он мог бы взять за образец.
С другой стороны автоматизация биржевых расчетов (особенно в 80-е годы) сделала возможным массовое применение сложных производных финансовых инструментов типа свопов, опционов на свопы и пр., что вызвало определенный культурный шок на рынке ценных бумаг. Сама запись по книгам учета брокерских операций стала фактически эквивалентом ценной бумаги. Даже для того, чтобы просто обратить эту запись в "бумажную" бумагу надо заплатить 25 долларов (при стоимости бумаг от 3 до 100 долларов делает целесообразность такого действия вообще проблематичным).
А электронный (безбумажный) билет, который сейчас внедряют авиакомпании - от билета в этом объекте одно название. Целый пласт возможных действий с бумажным билетом (типа экспертиза фальсификатов) для электронного билета приобретает совсем другую форму. Получается вроде и билет и не-билет одновременно.

2. Не очень понятно, на какой стадии  нужно решать вопрос о необходимости автоматизации того или иного процесса вообще и  в каких рамках нужно принимать решения об этом. Был случай, когда функциональное подразделения банка заказчика хотело иметь весьма навороченный отчет, который необходимо представлять в соответствии с требованиями ЦБ. Когда оценили трудоемкость разработки отчета, выяснилось, что за непредоставление этого отчета было предусмотрено наказание в виде существенно меньшей суммы денег, чем требовала разработка и предполагаемая поддержка отчета. Не очень понятно, можно ли было бы «отловить» эту ситуацию на этапе НИР или концепции? Не очень понятно, что могло бы заставить составителей ТЗ от Заказчика (прежде всего – ИТ-отдел) задаться  вопросом о необходимости реализации этого отчета при  написании ТЗ?
Решение было найдено потому, что ИТ-специалисты банка в силу ряда обстоятельств были интегрированы в "основную" деятельность по управлению деятельностью банка, что можно считать скорее исключением, чем правилом.   Но какие методики, стандарты  могли бы позволить «отлавливать» такие ситуации, соединяя представления разных специалистов ?

84

Системный Анализ и Требования / Re: Писать ли статью про ТЗ по ГОСТ 34.602?

« : 13 Декабря 2007, 00:11:45 »

Ой, Shur, как сказал. Прямо песня ....

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

85

Системный Анализ и Требования / Re: Писать ли статью про ТЗ по ГОСТ 34.602?

« : 12 Декабря 2007, 13:10:18 »

Теперь посмотрим на группы обобщённых сценариев взаимодействия (aka варианты использования) - что они содержат? Описание взаимодействия пользователей и системы. Откуда эти сценарии берутся, от заказчика? Нет, они являются результатом ПРОЕКТИРОВАНИЯ ВЗАИМОДЕЙСТВИЯ, как работы по определению хода развёртывания взаимодействия реактивной функции (в отличие от трансформационной), затребованной от системы на этапе ТЗ. Т.е. это материал для стадий 4/5 по ГОСТ 34.601 - "Эскизный проект", "Технический проект".
Ещё простой пример логики - что такого технического в модели бизнес-процессов и концепции, чтобы засовывать их в документ под названием ТЕХНИЧЕСКОЕ задание? Да ничего.

То, что варианты использования являются исключительно продуктом проектной деятельности - сильное утверждение.
1. Если есть уже старая система, на смену которой создается новая, то часть сценариев взаимодействия неизбежно будет унаследована новой системой.
2. Системы и даже понятие системы возникли раньше, чем для управления этими системами стали применять программы. Поэтому когда все автоматизированные ныне виды деятельности автоматизировались впервые, то содержание автоматизированной деятельности (взаимодействие человека с "неавтоматизированной системой") получалась именно "от заказчика". И никак иначе. Проектировщик новой системы вносит в неё своё технологическое содержание, но обязательно на фундаменте содержания, полученного от заказчика системы.
3. То что в нашей стране многие представления о том как именно нужно "делать дело"  появляются вместе с программными продуктами никак не умаляет значимости тех системных решений, которые принимались при проектировании "неавтоматизированных" систем (например, автомобилей, самолетов, электростанций, городов). Многие такие ныне работающие системы унаследовали принципы их создания и функционирования, которые возникли до появления компьютера и пока еще не пересмотрены. История таких системных решений для автоматизируемой деятельности может быть очень полезна для понимания текущих проблем деятельности Заказчика, из-за чего он и затеял новый проект по автоматизации. Поэтому в разделе "Характеристика объекта автоматизации" ТЗ представляется вполне уместным описание деятельности заказчика как системы, рассматривая понятие "система" в данном случае существенно шире чем "компьютерная система".

86

Системный Анализ и Требования / Re: Риски проекта без "правильной" проектной документации

« : 29 Ноября 2007, 22:46:01 »

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

Какого рода документы входят в документацию? Это и руководство пользователя(ей) и описание системы на разных уровнях (включая уровень разработчиков)?
1. Поддержка пользовательской (рабочей) документации может быть полезна для Заказчика, если у него будут появляться новые пользователи и будет актуальна организация их обучения. Весьма вероятно, что Заказчик неявным образом попытается переложить связанные с обучением проблемы на Вас (особенно если требования к квалификации персонала не оговаривались в договоре на создание системы или в документации).
2. Если обсуждается необходимость поддержки документации уровня разработчиков системы, то если у Заказчика нет своих ИТ-специалистов, которые  что-то своё с Вашей системой делают, то вряд ли он согласится поддерживать такую документацию.
3. Не очень понятна роль аналитика (постановщика задач?) в процессах сопровождения. Если предполагается, что  под сопровождением системы понимается её "ползучая модернизация" в ходе которой будут производиться доработки системы по постановкам, которые будет делать аналитик, то работать в таком режиме по договору "равномерного и непрерывного" сопровождения можно только при очень дружественных отношениях с Заказчиком. По хорошему каждую такую работу надо уже оформлять отдельными договорами или дополнениями к основному договору (по каждой работе надо иметь возможность согласовывать цены и объемы). А если такие задачи действительно небольшие и разработчики неплохо ориентируются в предметной области , то можно обойтись без выделенного аналитика. При интенсивных контактах с Заказчиком по поводу "непрерывного потока" небольших задач более актуален менеджер проекта (в основном на этапе заключения договора  и согласования условий работ) и архитектор, которые будет следить, чтобы на уровне программной реализации не разъехался изначальный замысел системы.
4. Если всё-таки новые постановки предполагаются, то если Вы полагаете, что документацию надо дорабатывать (для себя), то как раз затраты на документирование постановок задач по доработке в рамках сопровождения можно отнести на процессы проектирования. И просить отдельные деньги именно на проектирование решения по постановке, а не на документирование решений. Т.е. акцент сделать на понятие "проектирование", а не "документирование". И развеять иллюзии у Заказчика, насчет того, что системы "просто" программируют (без проектирования), если такие иллюзии у него существуют .

87

Системный Анализ и Требования / Re: Риски проекта без "правильной" проектной документации

« : 29 Ноября 2007, 17:32:20 »

1. ИМХО аргументация которую Вы предложили может быть убедительна для Вашего начальника, но вряд ли она будет убедительна для Заказчика (если этот внешний Заказчик- другая организация).
2. Документация является важным инструментом при работах по сопровождению системы. В тексте договора на сопровождение системы по идее должны быть предусмотрены Ваши обязательства по поддержанию работосопособности системы только в рамках описанного в технорабочей документации функционала и в соответствии с требованиями ТЗ. Иначе Вы рискуете "подписаться" на непредсказуемо большой объем работ.

88

Системный Анализ и Требования / Re: Управление требованиями

« : 13 Ноября 2007, 15:59:02 »

2 greesha: sorry, поправил (IDEF3 попутал .

89

Системный Анализ и Требования / Re: Управление требованиями

« : 13 Ноября 2007, 15:22:36 »

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

ИМХО, чтобы более нагладно представить суть обсуждаемого предмета  попытался представить ваше утверждение в IDEF0, но возникают некоторые трудности: IDEF не предполагает управление артефакатами (требваниями), а только управление функциями. Поэтому воспроизвести Ваше утверждение на приаттаченной схеме буквально (вариант 1) - не получилось. Вы имели в виду вариант 2 или вариант 3?

90

Бизнес-анализ и Целеполагание / Re: Регламентация процесса "Бухгалтерский учет"

« : 02 Ноября 2007, 15:36:49 »

Данная работа действительно "заказана" моим начальником. Что интересует его - дословно "прозрачность всех процессов предприятия" и уяснение, чем же действительно заняты многие службы, потому что иногда появляется мнение, что просто нифига не делают чесно говоря . Им был выделен процесс к моделированию "Бухгалтерский учет". Хотя как я понял - интересует его именно вопрос по улучшению взаимодействия служб и отделов с  отделом бухгалтериЯ. это начальный этап. В будущем планируется наложить на существующую бизнесс-модель предпрятия КИС. но это в далеком будущем

Фактически ставится задача организация управления на основе системы управленческого учета. А систему управленческого учета предполагается делать на основе системы бухгалтерского учета. Это очень опасное и принципиально неверное решение. Бухгалтерский и управленческий учет имеют принципиально разные цели и задачи. Несмотря на то, что и там и там учет ведется на счетах учета и для изменения состояния счетов используются проводки, структура счетов принципиально разная. Основная цель бухгалтерского учета - соотнести факты хозяйственной деятельности с некоей общепринятой стандартной моделью, которая универсальна. Т.е. бухгалтерия делается для "внешних" потребителей по отношению к Вашему предприятию - для акционеров и гос. органов. А управленческий учет должен максимально точно описывать специфику Вашего предприятия. Нужно чтобы понятия и содержание этих показателей были понятны конкретным работникам и использовались ими в качестве инструмента их деятельности. Они не должны нуждаться в трактовке бух. аудиторами и должны скорее отражать специфику энергетической отрасли: "полезный отпуск", "объемы передачи по уровням напряжения", структура потерь и пр.
Как правило, общее у этих учетов только первичка, поэтому если чем и можно воспользоваться из бух учета, так это первичными документами. Но тогда зачем лезть в бух учет?
Судя по всему для Вашего руководителя это первое в его жизни назначение, при котром он отвечает не только за производство, но и за финансы. Лучше бы начать решение этой задачи с назначения грамотного финансового руководителя (фин. директора, зам. ген. директора). Ключевое слово для решения задачи, которую вы пытаетесь решать не "бухгалтерия", а "финансовый менеджмент", "бюджетирование", управление финансовыми потоками. Есть ли у вас планово-экономический отдел? Какая роль отводится ему в этом начинании?
После того, как у руководителя пройдет ощущение, что деньги (вероятно, проблема будет решаться независимо и параллельно с Вашими попытками разобраться с бухгалтерией) деваются непонятно куда, скорее всего во весь рост станет проблема планирования деятельности, во всяком случае выяснится, что чтобы планировать деятельность на предприятии не хватает очень существенной информации (не связанной непосредственно с деньгами). Дальнейший сценарий зависит от того, кто Вы - сеть или сбыт?

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

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