GYM.sgp.PG.11 - Estructuras de Control

PROCEDIMIENTO DE GESTION GYM.SGP.PG.11

GESTION DE PROYECTOS Revisión: 0

ESTRUCTURAS DE CONTROL Fecha: 22/06/2008Página 1 de 9

1. OBJETIVO

Establecer los criterios para defi nir los mecanismos de control del Proyecto en los temas de venta, costo, plazo, avance y productividad.

2. DEFINICIÓN DE ESTRUCTURAS DE CONTROL

Las estructuras de control se defi nen como el ordenamiento de la información del Proyecto con el fi n de facilitar su control y lectura. Pueden defi nirse según diversos criterios, en función del monto, plazo, metrados, importancia, complejidad del trabajo, ubicación geográfi ca, disciplina, secuencia, etc. Las estructuras de control a usar serán defi nidas por el Gerente de Proyecto, en coordinación con su equipo. En función de la información a administrar, podemos defi nir las siguientes estructuras de control:

Figura 01 – Estructuras de Control para los diferentes procesos de control del Proyecto.

El Proyecto podrá además defi nir otras estructuras de control, de acuerdo a los mecanismos de control que decida implementar. Adicionalmente, el Cliente puede solicitar información ordenada de acuerdo a estructuras de control defi nidas por él. Las siguientes operaciones con información se ordenarán de acuerdo a las estructuras de control que se defi nan:

Toma de información de campo: avances, consumos de mano de obra, equipos, materiales, etc. Registro y procesamiento de esta información en los sistemas: ORACLE, SISPO, SISME, Almacenes,

Bases de Datos, Herramientas de Excel, etc. Ordenamiento de la información proveniente de los reportes generados por los sistemas.

Su objetivo es ayudar a controlar el Proyecto. Por ello deben mantener las características de simplicidad y consistencia a fi n de facilitar su entendimiento por todo el personal del Proyecto. Los criterios generales para defi nir las estructuras de control son los siguientes:

La toma de información de campo y su registro en los sistemas debe poder ser razonablemente sencilla, a fi n de alimentar los sistemas de manera confi able y oportuna.

Los reportes de los sistemas deben mostrar información que agregue valor al Proyecto, permitiendo el análisis y toma de decisiones.

Deben estar lo más vinculadas entre sí que sea posible, de modo que se reduzca la carga operativa que implica la toma y procesamiento de la información y la generación de reportes.

Este último criterio es muy importante. Vincular las estructuras signifi ca lograr que unas puedan obtenerse a partir de las otras a través de operaciones sencillas. En el caso más favorable, las cinco estructuras de control serán idénticas, de modo que una misma información podrá alimentar a todos los procesos mostrados en la fi gura 01. En el caso más desfavorable, las cinco estructuras serán totalmente diferentes, de modo que haya que tomar y procesar información de cinco maneras distintas para alimentar los mismos procesos. Ambos casos son muy poco probables, siendo lo usual un punto intermedio. Se muestra un ejemplo en la fi gura 02.




Figura 02 – Vinculación de estructuras de control.

2.1. Estructura de División de Trabajo:

Es la estructura con la que se ordena el Proyecto para elaborar el Cronograma General y posteriormente actualizarlo según el proceso de Control de Plazo. Consiste en dividir el Proyecto en las actividades que lo componen. Las actividades son las tareas específi cas que deben ser realizadas durante la ejecución de un Proyecto para llevarlo a cabo. Las actividades se defi nen en función de las necesidades del Proyecto y con el detalle necesario para poder plasmar las estrategias a utilizar a lo largo del Proyecto. Para defi nir las actividades es necesario:

Defi nir la Estructura de División del Trabajo (EDT) del Proyecto, también conocida como WBS (Work Breakdown Structure) por sus siglas en inglés. De manera general, un Proyecto puede tener la EDT siguiente:

Nivel 1: Proyecto. Nivel 2: Son las fases del Proyecto (Ingeniería, Procura o Construcción – aplicable sólo a

Proyectos EPC). Nivel 3: Ubicación Geográfi ca (Área, Sectores, etc.). Nivel 4: Son los Sistemas. Generalmente los Proyectos, para un mejor control de la ejecución, se

clasifi can en sistemas. Ejemplo: Sistema de Agua Fresca, Sistema de Combustible Diesel 2, etc. Nivel 5: Son las diferentes Disciplinas o Especialidades. Nivel 6: Son las Actividades en cada Sistema.

Descomponer cada nivel del EDT. Esta descomposición implica subdividir cada nivel del EDT en sus respectivos componentes y elementos, tal como se muestra en la fi gura 03:




NIVEL 1

NIVEL 2

NIVEL 3

NIVEL 4NIVEL 5

NIVEL 6

NIVEL 4

NIVEL 5

NIVEL 6

100110120130130.1130.1.1130.1.1.1130.1.1.1.1130.1.1.1.2130.1.1.1.3130.1.1.1.4

130.1.2130.1.2.1130.1.2.2130.1.2.2.1130.1.2.2.2

ALTO CHICAMA PROJECT INGENIERIA PROCURA CONSTRUCCIONSECONDAR Y CRUSHER Fresh Water Supply and Distrib Cimentaciones de bombas Excavación Relleno Encofrado Concreto

Fresh Water Piping System Estructuras Tuberías Fabricación Montaje

NIVEL 1

NIVEL 2

NIVEL 3

NIVEL 4

NIVEL 5

NIVEL 6

PROYECTO

FASES EPC

AREA SECTOR

SISTEMAS

DISCIPLINA

ACTIVIDAD

Figura 03 – Ejemplo de EDT.

2.2. Estructura de Control de Costos:

Es la estructura con la que se ordena el Proyecto para poder realizar el proceso de Control de Costos. Consiste en el ordenamiento del costo del Proyecto con el fi n de facilitar su control y lectura. Esta estructura será creada en el Sistema de Contabilidad (ORACLE), así como en los sistemas de Mano de Obra (SISPO), Equipos (SISME) y Almacenes. La información de costos generada por el consumo de los recursos será cargada en los sistemas de acuerdo a este ordenamiento.

Toda estructura de control incluye una doble clasifi cación de los costos:

Una clasifi cación por Rubros o Cuentas Contables, la cual es asignada a todos los Proyectos de manera automática: Materiales, Mano de Obra, Equipos, Subcontratos y Costos Indirectos.

Una clasifi cación de tipo técnico, defi nida por cada Proyecto en función de sus características y del análisis de sus requerimientos y necesidades. Los criterios de clasifi cación pueden ser por frente, partida, fase, recurso, requerimientos de retroalimentación del Área de Presupuestos, etc.




Con ello se obtiene una clasifi cación matricial de los costos. A continuación se defi nen dos tipos de estructura de control, en función de las metodologías de control de costos1 a ser tratadas posteriormente:

A. Metodología “1”:Es la metodología utilizada más frecuentemente en los Proyectos civiles y de edifi caciones. Se basa en la clasifi cación de costos según el criterio de Frentes y Partidas. La estructura de control resultante se muestra en la fi gura 04:

Figura 04 – Estructura de Control según Metodología “1”.

Se deberán tomar en cuenta los siguientes puntos:

La totalidad de los costos deben ser clasifi cados de acuerdo a la estructura de control de modo que las sumatorias de los subtotales por rubro y frente/partida deben ser iguales al costo total del Proyecto.

Los rubros o cuentas de Materiales, Mano de Obra, Equipos y Subcontratas integran el costo directo del Proyecto.

La cuenta de Costos Indirectos integra el total del costo indirecto del Proyecto. La cuenta de Costos Indirectos tiene defi nida una estructura de control estándar para todos los

Proyectos, la cual se adjunta al presente documento.

B. Metodología “2”:Es la metodología utilizada más frecuentemente en los Proyectos electromecánicos. Se basa en la clasifi cación de costos según el criterio de Fases y familias de Recursos. La estructura de control resultante se muestra en la fi gura 05:

1 Ver procedimiento GYM.SGP.PG.31 – Control de Costos




Figura 05 – Estructura de Control según Metodología “2”.

Se deberán tomar en cuenta los siguientes puntos:

La totalidad de los costos deben ser clasifi cados de acuerdo a la estructura de control de modo que las sumatorias de los subtotales por rubro y fase/recurso deben ser iguales al costo total del Proyecto.

Los rubros o cuentas de Materiales, Mano de Obra, Equipos y Subcontratas incluirán el costo directo y parte del costo indirecto del Proyecto. Por ejemplo, existe equipo directo (tractores) y equipo indirecto (camionetas), mano de obra directa (obreros) y mano de obra indirecta (tareadores), etc.

La cuenta de Costos Indirectos incluirá sólo la parte del costo indirecto del Proyecto que no se puede clasifi car en los rubros anteriores, como por ejemplo el Costo Financiero.

La cuenta de Costos Indirectos tiene defi nida una estructura de control estándar para todos los Proyectos, incluyendo aquellos que usen esta metodología. Debe tomarse en cuenta que todos los costos indirectos deberán ser cargados en ORACLE de acuerdo a las partidas estándar. Para ordenar los costos de acuerdo a lo indicado en los puntos anteriores, éstos deberán redistribuirse fuera del sistema.

Esta metodología también considera el rubro “Supervisión” (mostrada con un color diferente en la fi gura 04 por no ser una cuenta contable de ORACLE), el cual está compuesto por el personal de supervisión del Proyecto. Estos costos están incluidos en la cuenta estándar de gastos generales, por lo que también deberán ser separados de ella fuera del sistema. La supervisión también se divide en supervisión directa (ingenieros de campo) y supervisión indirecta (gerente de Proyecto).

Tal como está defi nida esta Estructura de Control, el direccionamiento de costos en ORACLE y los reportes requeridos por los procesos de Control de Costos y Control de Productividad no serán completamente compatibles. Los reportes de ORACLE deberán ser modifi cados fuera del sistema para encajar con los lineamientos descritos en los puntos anteriores.

2.3. Estructura de Control de Avances:

Es la estructura con la que se ordena el Proyecto para poder realizar el proceso de Control de Avances. Consiste en seleccionar y agrupar aquellas actividades que determinan el avance del Proyecto, siguiendo criterios generales de importancia, volumen y secuencia. El objetivo es seleccionar aquellas actividades que, a través de la medición de su avance, permitan refl ejar de mejor manera el avance del Proyecto en su conjunto. Con esta estructura se alimentan las herramientas de Control de Avance.




Figura 06 – Flujo de información para el Control de Avances.

2.4. Partidas de Control:

Es la estructura con la que se ordena el Proyecto para poder realizar el proceso de Control de Productividad. Consiste en seleccionar y agrupar aquellas actividades que determinan la productividad del Proyecto, siguiendo criterios generales de importancia, volumen y costo.

La productividad se defi ne como la efi ciencia en el uso de los recursos. Para calcularla es preciso cuantifi car el consumo de los recursos y dividirlos entre el avance que fue ejecutado con dicho consumo. El consumo de recursos ordenado por Partida de Control se obtiene de los sistemas (SISPO, SISME), por lo que está relacionado con la Estructura de Control de Costos. Los avances ordenados por Partida de Control se obtienen de la Estructura de Control de Avances. Es claro que estas estructuras deben estar necesariamente vinculadas a fi n de realizar un manejo efi ciente de la información.

Figura 07 - Flujo de información para el cálculo de IP de Mano de Obra.

Figura 08 - Flujo de información para el cálculo de IP de Equipos.




La Estructura de Control de Costos correspondiente a la Metodología “2” no considera un ordenamiento por actividad. Por lo tanto, además de la estructura de control de costos, es necesario crear en los sistemas (ORACLE, SISPO, SISME) las partidas de control a fi n de obtener los consumos de recursos ordenados por Partida de Control. Esto implica que unos recursos se codifi carán de acuerdo al esquema Fase/Recurso y otros de acuerdo al esquema Fase/Partida.

2.5. Ítems de Pago:

Es la estructura del Presupuesto de Venta que fi gura en el Contrato y que es usada para elaborar las Valorizaciones. Es defi nida por el Cliente. Puede estar vinculada con la Estructura de Control de Avances.

2.6. Estructuras de Control del Cliente:

En ocasiones el Cliente requerirá la elaboración de informes de acuerdo a estructuras de control requeridas por él. Generalmente, estos requerimientos están relacionados con el Cronograma General y/o con herramientas de Control de Avance (Curvas “S”). En estos casos, es recomendable realizar el control del Proyecto utilizando las estructuras propuestas por el Cliente y no generar estructuras paralelas internas a fi n de evitar multiplicar innecesariamente la carga de trabajo.

3. TOMA DE INFORMACIÓN

Una vez defi nidas las Estructuras de Control del Proyecto, es necesario defi nir los documentos que se deben generar en el campo y el fl ujo de la información necesario para llevar a cabo los procesos de gestión relacionados.

3.1. Flujo de información:

Ofi cina Técnica y Producción defi nirán los documentos a ser manejados por el Proyecto respecto a mano de obra, equipos, materiales, principales subcontratas y avance. El siguiente listado no es limitativo:

Reporte Diario de Operador: formato donde se colocan las horas máquinas trabajadas (HM) por los equipos, detallándose el frente y partida donde trabajaron.

Tareo Diario de Personal: formato utilizado para colocar las horas trabajadas por los obreros, detallándose el frente y partida donde trabajaron.

Vale de Salida de Almacén: documento físico que justifi ca el consumo de un material o el préstamo de un equipo menor o herramienta a producción, asignando el costo generado a un frente y partida determinado.

Vale de Subcontrata: documento físico que justifi ca un servicio brindado por un determinado subcontratista, asignando el costo generado a un frente y partida. Adicionalmente sirve de sustento para las valorizaciones presentadas por los subcontratistas.

Reporte de Avance: documento diario o semanal que elabora Producción con una relación de los avances ejecutados en determinadas actividades. Por ejemplo, reporte diario de viajes a botadero.

Adicionalmente se defi nirá el fl ujo a seguir por cada documento. El Gerente de Proyecto defi nirá los responsables de validar los documentos generados, detallando las fi rmas necesarias para cada documento.




Figura 09 – Ejemplo de fl ujo de información.

Los documentos generados en campo representan la alimentación directa de los procesos de control del Proyecto, radicando en este punto la importancia de cuidar y validar la información de los mismos. A continuación se presenta una matriz de algunos de los procesos que interactúan con los diversos documentos del Proyecto:

Figura 10 – Relación de documentación generada en campo y procesos de control.

3.2. Indicadores de Entrega Oportuna de Información:

El Gerente de Proyecto, en conjunto con Ofi cina Técnica, defi nirá los Indicadores de Entrega Oportuna de Información, que involucran:

Defi nir los documentos del Proyecto a controlar (ejemplo: tareo de mano de obra). Defi nir el plazo máximo para la entrega de los documentos por parte de los ingenieros de

Producción (ejemplo: tareos de mano de obra se entregarán máximo al fi nal de la jornada de trabajo del día posterior).

Defi nir al responsable de llevar el control de la entrega a tiempo de los documentos (ejemplo: el planillero será el responsable de controlar la entrega de los tareos de mano de obra).

A continuación se presenta los Indicadores de Entrega Oportuna de Información defi nidos para un Proyecto en particular:

Figura 11 – Ejemplo de indicadores de entrega oportuna de información.

Tareador Ingeniero de campo Planillero Gerente de Proyecto

Generación de tareos Validación de tareos Ingreso de tareos a SISPO Revisión de la Planilla

Planillero Planillero Oficina Principal PlanilleroGeneración y entrega de

Reportes Generación y entrega de

boletas de pagoProcesamiento de la

PlanillaEnvío de Planilla al Dpto.

de Sist. y Comunicac.

INGENIEROS % IRREGULARIDAD CALIFICACIÓN PROMEDIO (4 SEMANAS) EVOLUCIÓN

Luis Puicon 100% Por Mejorar 66%Franko Ramos 100% Por Mejorar 100%Cesar Pretell 100% Por Mejorar 93%Emilio Samaniego 70% Por Mejorar 70%María Sipion 67% Por Mejorar 55%Hilario Sanchez 67% Por Mejorar 85%Ivanov Mormontoy 50% Conforme 54%Máximo Alegría 33% Conforme 83%Antonio Nieto 33% Conforme 29%Renzo Flores 29% Conforme 14%Luis Sosa 25% Óptimo 38%Eduardo Trujillano 15% Óptimo 11%William Diaz 14% Óptimo 36%Julio Villanueva 0% Óptimo 10%José De La Flor 0% Óptimo 0%Jeisen Yumbato 0% Óptimo 0%Humberto Ortiz 0% Óptimo 0%Gerardo Mendoza 0% Óptimo 9%Carlos Luna 0% Óptimo 0%




4. MATRIZ DE RESPONSABILIDADES

GP OT Pr1. Defi nición de las estructuras de control necesarias √2. Defi nición de los documentos a generar para alimentar las

estructuras de control √ √

3. Defi nición de fl ujos de información √ √

4. Defi nición de responsables de entrega oportuna de información √

5. Defi nición de responsables de procesamiento de información √

6. Elaboración de indicador de entrega oportuna de información √

GP: Gerente de ProyectoPr: ProducciónOT: Ofi cina Técnica

5. REFERENCIAS Y ANEXOS

5.1. Mejores Prácticas

Una estructura de control debe ser pensada tomando en cuenta los siguientes criterios:

Debe permitir el control de los factores claves de éxito del proyecto. Debe permitir la defi nición de objetivos cuyo cumplimiento pueda ser medido. Debe facilitar la ejecución de los procesos de control de costos, plazo, avance y productividad. Debe permitir el seguimiento adecuado de los resultados de la gestión. Debe permitir reducir el trabajo operativo utilizando los sistemas con que cuenta la empresa:

ORACLE, SISPO, SISME, S10, etc. Debe estar relacionada con los recursos y capacidad disponible de toma y procesamiento de la

información.

5.2. Documentos relacionados

GYM.SGP.PG.09 – Análisis del Proyecto GYM.SGP.PG.10 – Personalización del Sistema de Gestión GyM al Proyecto GYM.SGP.PG.13 – Cronograma General GYM.SGP.PG.22 – Control de Plazo GYM.SGP.PG.23 – Control de Avances GYM.SGP.PG.31 – Control de Costos GYM.SGP.PG.33 – Control de Productividad (IP) GYM.SGP.PG.42 – Valorizaciones con el Cliente

5.3. Anexos

GYM.SGP.PG.11-A01 – Listado de Partidas de Control Estándares para Costos Indirectos. GYM.SGP.PG.11-A02 – Vale de Salida (ejemplo) GYM.SGP.PG.11-A03 – Vale de Subcontrata (ejemplo) GYM.SGP.PG.25-F01 – Tareo Diario de Personal GYM.SGP.PG.26-F01 – Reporte Diario de Operador

GYM.sgp.PG.11 - Estructuras de Control

Documents

Transcript of GYM.sgp.PG.11 - Estructuras de Control