Андрей Орлов - Записки автоматизатора. Профессиональная исповедь
- Название:Записки автоматизатора. Профессиональная исповедь
- Автор:
- Жанр:
- Издательство:неизвестно
- Год:неизвестен
- ISBN:нет данных
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Андрей Орлов - Записки автоматизатора. Профессиональная исповедь краткое содержание
Записки автоматизатора. Профессиональная исповедь - читать онлайн бесплатно полную версию (весь текст целиком)
Интервал:
Закладка:
В отзывах на первую интернет-публикацию записок достаточно часто спрашивали, где можно почитать про СИВСы. Все поисковые сервера Интернета при попытке что-нибудь о них узнать, дружно отправляют меня к моим же запискам. Похоже, что вся информация так и осталась в 1970-х…
Это не так. Сейчас это именуется dataflow diagram (или audit diagram, или еще как угодно в зависимости от рассказчика) и используется при описаниях процессов. Один из примеров СИВС-подобной нотации – ARIS EEPC, используемая в одноименном продукте (к сожалению, сильно недешевом). – Д. К.
СИВСом называлась диаграмма, по оси абсцисс которой откладывалось время, а по оси ординат – организации, структурные подразделения или сотрудники. Когда меня учили, на СИВСе отображали документы и действия с ними. Я размещаю на СИВСе все объекты, которые существенны в бизнес-процессе, включая пачки денег и товары, если это необходимо. Получается очень наглядно и понятно даже неспециалисту. Не слишком хорошо удается отобразить только циклы. Для их отображения я просто выделяю участок диаграммы, под которым пишу текстом «Повторяется 10 раз» или «Повторяется, пока все не согласятся с текстом»
В последние годы для рисования СИВСов я использую Microsoft Visio. Пример приведен ниже.
Да, вполне достаточно любой рисовалки, хоть текстового редактора (даже лучше не увлекаться дорогими продуктами, так как смысл работы может утонуть в процессе увлекательного освоения ультрамодной технологии). – Д. К.

Рис. 5. Пример фрагмента СИВС
Следует отметить, что СИВС в моей интерпретации не предполагает автоматической генерации программ и баз данных. Эта штука принципиально недоформализована, что позволяет ее делать настолько наглядной, насколько это нужно. Если же вы хотите автоматизировать всю разработку от описания бизнес-процессов до кодов, то нужно использовать те средства поддержки case-технологии, которые сейчас есть на рынке.
Помимо осознания информационных потребностей компании вам еще очень неплохо сформулировать основные задачи ИТ-подразделений. Не надейтесь, что ваше мнение на этот счет совпадает с мнением руководства. На самом деле подразделения ИТ не только могут работать, но и на самом деле работают, руководствуясь разными целями, и единодушие среди топ-менеджмента хотя бы в этих вопросах будет для вас совсем не лишним. Разберем пример документа.
Концепция управления подразделениями ИТ
1. Направление ИТ состоит из подразделений, занятых в основном обслуживанием других подразделений компании, обеспечивающих поступление прибыли. Сами подразделения ИТ планово затратны и не ориентированы на получение прибыли с помощью продажи оборудования, программ или услуг.
Это означает, что при проектировании программного обеспечения и проработке технологических решений подразделения не закладываются средства на возможность дальнейшей продажи решений, поскольку последнее требует существенно больших ресурсов в процессе разработки. С другой стороны, топ-менеджмент компании не рассчитывает на продажу этих решений и не соблазняет такими мыслями сотрудников ИТ-подразделений. Следует помнить, что предпродажная подготовка программного продукта может составлять более девяноста процентов его стоимости.
2. Сотрудники ИТ-подразделений могут иметь и высказывать свое мнение по вопросам организации торговли, развития фирмы и другим вопросам, находящимся вне зоны их основной специализации, но всегда выполняют решения профильных менеджеров компании, какими бы странными они им ни казались.
Как мне кажется, для этого пункта альтернативы не существует. То есть она есть, но ровно одна: айтишник становится исполнительным директором или кем-то похожим. Но в этом случае он перестает быть айтишником…
Как следствие, инициативы создания и развития программных продуктов пресекаются, если они не одобрены топ-менеджментом компании.
3. Существуют приоритеты в очередности использования ресурсов для решения задач подразделениями ИТ (представлены в порядке убывания значимости для компании, в которой вы работаете):
– Обеспечение возможности принятия стратегических решений топ-менеджментом компании (организация учета и отчетности, позволяющей принимать решения);
– Увеличение количества продаж (изменения в ПО для проведения торговых акций) и скорости продаж в магазинах (изменения ПО для облегчения и ускорения работы в кассовых программах);
– Обеспечение роста производительности и удобства работы других пользователей.
Полезно также помнить, что автоматизация учета должна предшествовать автоматизации планирования. Почему-то иногда пытаются сделать наоборот. – Д. К.
Тоже вроде все ясно. Но хочется, чтобы все желания исполнялись сразу. Я в таких случаях цитирую концовку сказки Сергея Михалкова «Жадный Вартан»: «Больших семь шапок из овцы / Не выкроишь никак!»
Есть три сказки, с помощью которых удобно иллюстрировать процесс постановки задачи и последующего внедрения.
1. «Жадный Вартан» (когда урезанный бюджет приводит к сильному сужению рамок проекта, что иногда выливается во внедрение журнала хозопераций вместо полноценной системы).
2. «Каша из топора» (когда заключается договор с узкими рамками, которые впоследствии вместе с бюджетом плавно расширяются внедренцем).
3. «Сытный бублик» (когда результат достигается только после многочисленных недовнедрений, в процессе которых набирается опыт и появляется понимание того, какой все-таки был необходим результат). Последняя попытка в таком случае оказывается удачной, и руководитель восклицает, подобно деду из сказки: «Что же ты мне сразу этот сытный бублик не дала?!» – Д. К.
4. Предложения по доработкам и развитию ПО и оборудования могут выдвигать и обсуждать все сотрудники компании, однако выполнению подлежат только заявки, утвержденные руководителями направлений уровня заместителя директора.
Вас удивляет, что это надо писать? Вот поверьте, надо.
Теперь вам придется определиться, воспользоваться покупной системой или программировать самим. И то и другое имеет свои очевидные минусы: покупные системы никогда не заточены под ваши задачи, а на собственную требуется такое количество ресурсов (и денег , и людей , нанимаемых не на постоянную работу, а «под задачу» – что, бесспорно, ускоряет решение этой задачи, – и, что самое важное, времени ), какое в большинстве случаев просто недоступно.
Читать дальшеИнтервал:
Закладка: