Logo ru.artbmxmagazine.com

Erp разработка программного обеспечения с переменными временными рамками

Оглавление:

Anonim

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

разработка-программное обеспечение ERP-предельные сроки-временные переменные-1

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

В этом документе объясняется, как были разработаны подсистемы Caja, Banco и Collections and Payments, принадлежащие линии ERP Finance, и каким образом управление их ресурсами соответствует времени выполнения запланированных графиков. рациональное использование ресурсов и с требуемым качеством. Заботясь об их соответствующих жизненных циклах, задачи критического пути управляются, и для критической цепочки создаются различные типы буферов или демпферов, чтобы гарантировать соблюдение крайнего срока, даже до запланированной даты, поддерживаемого использованием из проекта MS.

развитие

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

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

Концепция проекта

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

Управление человеческими ресурсами любого проекта включает в себя процессы, организованные и направляемые командой, отвечающей за его достижение, которая состоит из людей, которых характеризуют роли и обязанности в соответствии с их компетенциями, которые позволяют им внести свой вклад в успешное завершение проекта. (1) Независимо от этого, члены команды должны в значительной степени участвовать в планировании проекта и принятии решений, что усиливает приверженность всех участников проекту.

Планирование проекта

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

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

Распределение ресурсов

Распределение ресурсов проекта может быть сделано с фиксированной продолжительностью и прямым распределением ресурсов или настройкой MS Project с фиксированной работой. Поэтому выражение стоимости должно быть ориентировано в соответствии с продолжительностью задач и назначенными им ресурсами:

  • Фиксированная продолжительность. Когда ввод данных в проект является продолжительностью и с этого момента выполняется распределение ресурсов. Исправлена ​​работа. Когда определенная работа доступна для определения продолжительности и стоимости задач, в этом случае продолжительность задач определяется на основе распределения ресурсов. Фиксированные ресурсы. Распределение ресурсов разработано с учетом их доступности.

На основе структуры разбивки заданий (EDT) определяются необходимые ресурсы, такие как рабочая сила, оборудование и материалы для каждой задачи, и работу по заданию необходимо импортировать в проект MS.

Планирование разработки подпроектов линии «Финансы» осуществлялось исходя из конфигурации под вариант с фиксированными ресурсами (фиксированные единицы).

Разбивая задачи

Благодаря выполнению проекта, выполняемые действия должны быть разбиты на подпроекты, этапы, сводные задачи и конкретные задачи (см. Рисунок 1) для достижения организации проекта в соответствии с вашими конкретными интересами. Эта структура дезагрегации позволяет анализировать последовательность выполнения с ее соответствующими перекрытиями на основе доступности ресурсов и технологических зависимостей, определенных для каждого проекта. Это облегчает правильную последовательность, чтобы облегчить ее контроль.

Сокращение сроков

Максимальная длительность проекта, полученная в ходе планирования, всегда ставится под сомнение клиентом и заинтересованными сторонами, обычно запрашивая такое же сокращение, что приводит к распределению ресурсов неэффективным или неизбирательным образом. Возможно, удастся добиться успеха во время «бомбардировки» ресурсов на критическом пути, сократив время выполнения проекта, но неудача в этом смысле может излишне увеличить запас некритических задач, принося излишние ресурсы с низкой производительностью, стимулируя беспорядок и ограничение использования этих ресурсов в других задачах или проектах, приоритетных в Фонде общих ресурсов.

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

Тогда проблема заключается в том, чтобы определить, «где» ресурсы необходимы, и ответ заключается в «задачах критического пути»:

На рисунке 2 показан фрагмент планирования подсистемы «Сборы и платежи», где выделен критический путь проекта. Поэтому из длительности и стоимости наклон рассчитывался по формуле:

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

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

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

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

Δ PP 2 P 1

Где P1 - планирование, предусмотренное в первом варианте планирования, а P2 - второе. ΔP - это вариация.

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

Однако возник вопрос: с какой задачи начать, с самой длинной продолжительности?

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

Алгоритм сокращения времени проекта

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

Рисунок 3. Шаги, чтобы следовать, чтобы сократить время критических задач пути.

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

Фонд общих ресурсов (FRC)

В случае таких проектов, как ERP-Куба, которые из-за своего размера или особых характеристик делают необходимым работу в многопроектной среде для совместной работы, крайне важно создать интеграционный процесс с использованием интегрированного управления проектами с момента создания и использования FRC для всех подпроектов. Таким образом, ресурсы могут перемещаться в интересах организации с учетом приоритетов подпроектов, которые позволяют принимать соответствующие решения.

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

Таблица 1. Ресурсы Финансовой линии.

Ресурс Коллекции и платежи коробка Банка Общее количество
компьютеры 19 12 7 38
портативный компьютер один один один 3
Ученики 17 10 5 32
Учителя два два два 6

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

Изучение условий для выполнения заданий

До сих пор распределение ресурсов было объяснено с корректировками в соответствии с требованиями клиентов и заинтересованных сторон; Тем не менее, были и другие факторы, которые необходимо учитывать: то, что среднестатистическому программисту требуется три часа для разработки функциональности средней сложности, не означает, что три могут сделать это за один раз. Есть процессы, которые по своей природе требуют дополнительного времени, чтобы материализоваться. В этом смысле технологическая схема позволяет изучить условия труда, чтобы определить целесообразность включения новых ресурсов.

Иллюстративный пример на макроуровне в программных решениях описан на рисунке 4, где показана схема подсистем, которые должны интегрировать решение, предусмотренное для продукта CEDRUX, в результате выполнения проекта ERP-Cuba в первой области.

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

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

Из этого можно сделать вывод, что, хотя он разрабатывался в 24-часовой рабочей системе в течение 7 дней недели (24/7), было бы невозможно найти 22 человека в 3 8-часовой рабочей смене на машинах, предназначенных для разработки. Система бухгалтерского учета: 1 человек будет отсутствовать.

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

Защита, ограничения, ограничения, буферы и буфер

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

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

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

Контроль исполнения

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

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

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

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

SPI и CPI рассчитываются на основе значений, предложенных MS Project в таблице накопленных значений по разрезам.

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

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

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

Закрытие проекта

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

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

Выводы

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

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

Библиографические ссылки

  1. Институт управления проектами. Руководство по управлению проектом. Сумма знаний. PMBOCK Guide 2000 Edition. Тонкий. М Верез. Комплексное управление проектами. Администрация и финансы. http: //www.monographies.com. 2 октября 002.р. Мария. А. Верез. Поддержка Новых Технологий информатики и связи в Интегрированном Управлении Проектами в рамках Совершенствования Бизнеса. BETSIME. Журнал издается в августе 2001 г. ISNN 1029-5178. Комплексное управление проектами с использованием новых информационных и коммуникационных технологий. Учебник Под редакцией CETA. ISPJAE. Куба. 2 003. Национальный центр авторского права. CENDA. Работа защищена регистрацией. 07685-7685. Морено Р. Критическая цепь в программных проектах. Первый конгресс проектов. Испания. 2004.Дурренбергер, М. Заработанная стоимость. http://oakinc.com/pdf/ev/tutorial.pdf. 2004 Slim. Комплексное управление проектами с использованием информационных технологий и коммуникаций. Учебник DEADE. Испания, ISPJAE. 2004.Amendola. Стратегический и тактический в управлении и управлении проектами. Управление проектом. Политехнический университет Валенсии. 2004. Дельгадо Р. Диск интегрированного управления проектами. Связано с книгой Полупрезентационных курсов. ISBN 959-16-0251-3. 2004Apaolaza U. вклад критической цепи против классического управления проектами. IX Инженерный конгресс организации / Испания. 2005.Дельгадо Р. Метод цепной организации и его связь с интегрированным управлением проектами с использованием профессиональных компьютерных систем. UPADI. Атланта. ЕВРОСОЮЗ.2006 Дельгадо Р. Преподавание Интегрированного управления проектами при поддержке ИКТ по ​​смешанной модели. Fobdes. 2006. Диплом

Контактная информация

Имя и фамилия: Донел Васкес Самбрано

Дата рождения: 27 сентября 1981 г.

Адрес: C: 25 No: 5 e / 4ta и 6ta RPTO Рамон Кинтана.

Адрес электронной почты: [email protected]

Квалификация: инженер по информатике.

ПРОФЕССИОНАЛЬНАЯ ДЕЯТЕЛЬНОСТЬ

В 2008 году окончил UCI по специальности «Информатика». В дипломной работе он представил SIVEMA, систему продажи товаров по оптовым ценам с поддержкой мультивалютности.

С начала 2008 года он работал в системах управления предприятиями, в частности, в области бухгалтерского учета, финансов и управления затратами, связанными с продуктом CEDRUX: Integral Management System. В настоящее время он работает в области исследований в области электронной коммерции и электронного бизнеса, выполняя расширение функциональных возможностей SIVEMA для осуществления всех видов продаж.

Дополнительное время получено при интерполяции.

Constraint. Сокращение времени на выполнение задач, находящихся на критическом пути, что достигается за счет распределения ресурсов в соответствии с требованиями клиента.

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

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

Erp разработка программного обеспечения с переменными временными рамками