• Главная
• Юридпсихология
• Этика эстетика
• Электротехника
• Эктеория
• Физика
• Управление персоналом
• Уголовный процесс
• Уголовное право
• Схемотехника
• Стратегический менеджмент
• САПР
• Ресторанно-гостиничный бизнес бытовое обслуживан
• Реклама и PR
• Режущий инструмент
• Неопределено
• Метрология
• Матметоды в эк-ке
• Исторические личности
• Искусство и культура
• Информатика
• Иностранные языки
• Гражданское процессуальное право
• Гражданское право
• Государственное регулирование и налогообложение
• Сонник
• Карта сайта

Информационные системы в экономике
Что же заставляет банки разрабатывать предприятия и банки свои АИС собственными силами: ·        Во-первых, это конечно относительно низкая стоимость таких разработок (по сравнению с покупными). Как правило, к существующим подразделениям департамента информатизации, таким как: управление эксплуатации, управление эксплуатации вычислительной сети и средств связи, экспертно-аналитическое управление (постановка задач), добавляется лишь новая структура: управление развития и разработки АИС, что, как правило, не влечет за собой больших финансовых затрат. ·        Во-вторых, собственная разработка - это максимальная ориентация на реализацию бизнес - процессов предприятия или банка, его уникальных финансовых и управленческих технологий, складывающихся годами. ·        В третьих, это позволяет обеспечивать значительно более высокий уровень безопасности и независимости от внешних факторов. ·        В четвертых, оперативная реакция на изменения правил игры на рынке. Вместе с тем при собственной разработке необходимо решить целый комплекс организационно-технических задач, которые позволили бы избежать ошибочных решений Во-первых, правильный выбор архитектуры построения вычислительно-коммуникационной сети и ориентация на профессиональные СУБД. По экспертным оценкам собственные разработки АИС в 53% базируются на СУБД Oracle, около 15% на Informix, 22% - другие СУБД. Во-вторых, использование при разработке современного инструментария (CASE средства, эффективные средства разработки: Delphi, Designer2000, Developer2000, SQL-Stations и т.п.). В третьих, мультизадачная инфраструктура разработки проекта, когда конкретный модуль АИС ведет группа разработчиков с взаимосвязанным перечнем задач, построенная на принципах полной взаимозаменяемости, т.е. функционирование данного модуля АИС и его развитие не связано с одним конкретным разработчиком. В четвертых, применение эффективных организационно-технических средств по управлению проектом и контролю версий АИС. Только при соблюдении этих основных положений можно рассчитывать, что собственная разработка окажется конкурентной и эффективной. В противном же случае можно столкнуться с эффектом "неоправданных ожиданий" - это в лучшем случае, а в крайнем случае вообще задуматься о смене АИС. При этом, смена АИС может вызвать как непосредственно смену клиентских модулей и табличной структуры БД, так и потребовать замены серверного и клиентского аппаратного и общесистемного программного обеспечения, включая СУБД, а это дело не дешевое. Поэтому очень важно при выборе варианта реализации АИС сразу решить вопрос о возможностях экспорта/импорта данных в создаваемой системе. При правильном решении данного вопроса смена АИС, если в ней все-таки возникнет необходимость, произойдем практически безболезненно для функциональных подразделений. В отличие от банковских структур крупные отечественные промышленные предприятия сейчас только подходят к осознанию явной необходимости внедрения и развития корпоративных информационных систем как одной из основных компонент стратегического развития бизнеса. В связи с этим в недалеком будущем можно ожидать расширение рынка корпоративных информационных систем и в последующем его значительно роста. Учитывая тесную интеграцию финансовых и промышленных структур можно полагать, что основой построения корпоративных систем финансово-промышленных групп будут являться, используемые в их финансовых учреждениях, АБС. 4.2 Этапы разработки автоматизированных информационных систем. Таблица 3.Этапы проектирования АИС и их характеристики.
№	Наименование этапа	Основные характеристики
1	Разработка и анализ бизнес - модели	Определяются основные задачи АИС, проводится декомпозиция задач по модулям и определяются функции с помощью которых решаются эти задачи. Описание функций осуществляется на языке производственных (описание процессов предметной области), функциональных (описание форм обрабатываемых документов) и технических требований (аппаратное, программное, лингвистическое обеспечение АИС). Метод решения: Функциональное моделирование. Результат: 1.Концептуальная модель АИС, состоящая из описания предметной области, ресурсов и потоков данных, перечень требований и ограничений к технической реализации АИС. 2.Аппаратно-технический состав создаваемой АИС.
2	Формализация бизнес - модели, разработка логической модели бизнес -процессов.	Разработанная концептуальная модель формализуется, т.е. воплощается в виде логической модели АИС. Метод решения: Разработка диаграммы "сущность-связь" (ER (Entity-Reationship) - CASE- диаграммы). Результат: Разработанное информационное обеспечение АИС: схемы и структуры данных для всех уровней модульности АИС, документация по логической структуре АИС, сгенерированные скрипты для создания объектов БД.
3	Выбор лингвистического обеспечения, разработка программного обеспечения АИС.	Разработка АИС: выбирается лингвистическое обеспечение (среда разработки - инструментарий), проводится разработка программного и методического обеспечения. Разработанная на втором этапе логическая схема воплощается в реальные объекты, при этом логические схемы реализуются в виде объектов базы данных, а функциональные схемы - в пользовательские формы и приложения. Метод решения: Разработка программного кода с использованием выбранного инструментария. Результат: Работоспособная АИС.
4	Тестирование и отладка АИС	На данном этапе осуществляется корректировка информационного, аппаратного, программного обеспечения, проводится разработка методического обеспечения (документации разработчика, пользователя) и т.п. Результат: Оптимальный состав и эффективное функционирование АИС. Комплект документации: разработчика, администратора, пользователя.
5	Эксплуатация и контроль версий	Особенность АИС созданных по архитектуре клиент сервер является их многоуровневость и многомодульность, поэтому при их эксплуатации и развитии на первое место выходят вопросы контроля версий, т.е. добавление новых и развитие старых модулей с выводом из эксплуатации старых. Например, если ежедневный контроль версий не ведется, то в как показала практика, БД АИС за год эксплуатации может насчитывать более 1000 таблиц, из которых эффективно использоваться будет лишь 20-30%. Результат: Наращиваемость и безизбыточный состав гибкой, масштабируемой АИС

Рис.2. Последовательность трансформации бизнес-модели в объекты БД и приложения.

Разработка и анализ бизнес-модели

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

·        Получения информации;

·        Переработка информации;

·        Анализа, подготовки и принятия решения.

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

·        руководство теряет целостную картину происходящего;

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

·        это приводит к падению производительности и вызывает ощущение недостатка в ресурсах: людских, технических, коммуникационных и т.д.;

·        приходится расширять штат, вкладывать деньги в оборудование новых рабочих мест, помещения, коммуникации, обучение новых сотрудников;

·        для производственных предприятий увеличение штата может повлечь изменение технологии производства, что потребует дополнительных инвестиций;

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

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

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

ГЛАВА 5. Стандарты управления MRP,  MRP II, ERP, CSRP.  CRM-системы

5.1 Основные стандарты информационных систем

Не существует специальных стандартов, регламентирующих функции КИС, но как правило такие системы ориентируются на широко распространенные методологии MRPII и ERP, фактически являющиеся стандартами управления бизнесом. Данные стандарты разработаны американским обществом по контролю за производством и запасами (American Production and Inventory Control Society, APICS).

Исходным стандартом систем управления предприятием стал стандарт MRP (Material Requirements Planning), появившейся в 70-х годах. Он включает в себя планирование материалов для производства.

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

Таким образом, партии исходных материалов поступают одна за другой как бы «проталкивая» ранее поступившие по всем стадиям производственного процесса. Принцип «Толкающей системы»: Изготавливать узлы и поставлять их на следующую стадию производства, где они необходимы, или на склад, тем самым «проталкивая» материалы по производственному процессу в соответствии с планом.

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

В каких случаях использование MRP систем  является целесообразным?

Прежде всего, необходимо заметить, что MRP системы разрабатывались для использования на производственных предприятиях. Если предприятие имеет дискретный тип производства с относительно длительным циклом производства (Сборка на заказ - ATO, Изготовление на заказ - MTO, Изготовление на склад - MTS,  …), т.е. когда для выпускаемых изделий имеется ведомость материалов и состав изделия (разузлование), то использование MRP системы является логичным и  целесообразным.

Если предприятие имеет процессное производство (Process Industry), то применение MRP функциональности оправдано в случае относительно длительного производственного цикла (наличиеMPSпланирования).

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

MRP системы базируются на планировании материалов для удовлетворения потребностей  производства и включают непосредственно функциональность MRP , функциональность по описанию и планированию загрузки производственных мощностей CRP (Capacity Resources Planning) и имеют своей целью создание оптимальных условий для реализации производственного плана выпуска продукции.

Основная идея MRP систем состоит в том, что любая учетная единица материалов или комплектующих, необходимых для производства изделия, должна быть в наличии в нужное время и в нужном количестве.

Основным преимуществом MRP систем является формирование последовательности производственных операций с материалами и комплектующими, обеспечивающей  своевременное изготовление узлов (полуфабрикатов) для реализации основного производственного плана по выпуску готовой продукции.

Основные элементы MRP

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

Рис. 3.  Основные элементы MRP

В упрощенном виде исходную информацию для MRP системы представляют следующие элементы:

Основной производственный план-график - Master Production Schedule(MPS)

На практике разработка MPS представляется петлей планирования. Первоначально формируется черновой вариант для оценки возможности обеспечения реализации по материальным ресурсам и мощностям.

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

После проведения необходимых итераций MPS утверждается как действующий и на его основе осуществляется запуск производственных заказов.

Рис. 4. “Петля” MPS / MRP планирования

Ведомость материалов, состав изделия

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

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12