Sebastian Durandeu Blog

  • Visitantes

Archive for the ‘FIUBA’ Category

Algo de Marketing

Posted by sebastiandurandeu on December 20, 2010

Este es un resumen sobre algunos conceptos de marketing que armé, basado en una clase de la materia Administración y Control de Proyectos II de FIUBA. La clase fue dada por Mariano Stampella, de FDV Solutions.

Intro

Def: Maximizar el beneficio por la venta. Satisfacer necesidades.

+ algunos conceptos:

  • Necesidad: Carencia
  • Deseo: Expresión de satisfacer necesidad
  • Demanda: Suma de deseos
  • Valor: Beneficios – Costos de compra
  • Satisfacción: Grado de cumplimiento de expectativas
  • Direct Marketing: Comunicarse directamente con el cliente, no usar publicidad (ej. e-mailing campaigns)
  • Online Marketing: Marketing a través internet.
  • Buzz Marketing: “The strategic use of word of mouth.”
  • 4p’s del Marketing ó Marketing Mix (herramientas – acción de marketing):
    • Producto. Matriz de Ansoff. Posicionamiento del producto (imagen mental de producto).

clip_image001

    • Precio
    • Plaza
    • Promoción
Algunos Conceptos de Ventas
  • Sales Funnel: Proceso de Ventas
  • Sales Lead: Potencial cliente. Simplemente un contacto. Entry point for sales funnel.
  • Sales Prospect (siguiente al lead): Potencial cliente que mostró interés en el producto que ofrece la empresa.
    • Prospecting: Generación de demanda. Prospecting is simply discarding all the unqualified leads and retaining the "gold".
    • What is a prospect? For most salespeople, a prospect is someone that is currently looking for the kinds of products or services that their organization provides. (http://www.solutionsellingblog.com/)
Algunos Conceptos de Modelos de Negocio + Planificación Estratégica
  • Long Tail
    • Vender poco de muchos productos distintos (vs. vender mucho de pocos productos – hits- iguales). Es muy barato producir cosas diferentes que se ajusten a cada comprador. Se puede tener un inventario casi infinito. Ejemplos Amazon – Netflix
    • El contrario es el clásico principio de Pareto donde el 80% de los ganancias viene del 20% de los productos

clip_image002

  • Bricks and Clicks (AKA click-and-mortar): Modelo de negocio en el cual se tiene presencia física – un local- (bricks) y presencia online (clicks).
  • Mercado –> Segmento –> Nicho
    • "Por ejemplo, las personas que eligen viajar en avión, para trasladarse de un país a otro, representan un segmento de mercado. Por su parte, aquel grupo de personas que eligen la clase ejecutiva (business class) representan un nicho de mercado. En todo caso, el segmento de personas que eligen viajar en una línea aérea son claramente identificadas y diferentes del segmento de personas que deciden viajar en bus o tren" (http://intelectiva.blogspot.com/2009/07/diferencias-entre-mercado-y-nichos.html )
    • Un nicho de mercado ideal es aquel que tiene el tamaño necesario como para ser rentable (Philip Kotler)
  • Integración Vertical vs. Integración Horizontal
    • Vertical: Comprar proveedores y clientes. Para controlar desde la producción hasta la venta al consumidor final.
    • Horizontal: Comprar para expandirse a otros mercados y ser proveedores también en estos.
  • Core Competences
    • Que puedo hacer mejor que el resto? Que es lo que mejor hago? Que te diferencia? Obtener ventaja competitiva con esto.
    • Introducido por C.K.Prahalad and Gary Hamel
    • Que no puede se imitado por competidores.
    • Puede ser también una relación con un cliente, no solo know-how
    • Si no tenés core competences, solo podes competir en precio.
    • La las competencias esenciales son la base de la ventaja de mi negocio
    • Concentrarme en mis core competences e intentar tercerizar el resto.
    • (http://www.mindtools.com/pages/article/newTMC_94.htm)
  • Cadena de Valor (value chain)
    • La serie de actividades de mi negocio que terminan generando valor al cliente.
    • Introducida por M. Porter

Con que seguir? Social Media Marketing: http://bizthoughts.mikelee.org/biz-idea-social-media-market-research-app.html#disqus_thread

Posted in Business, FIUBA, Marketing | Leave a Comment »

Clojure: Links de Introducción

Posted by sebastiandurandeu on November 15, 2010

Clojure es un lenguaje dinámico y funcional que se puede ejecutar sobre la JVM (Java Virtual Machine) desarrollado por Rich Hickey. Es parte de la familia de lenguajes “herederos” de LISP.

El lenguaje trabaja con datos inmutables, con lo cual no puedo modificar los valores que defino. Si digo que “a” vale 10, para hacer que  valga 11, necesito volver a crear “a” con valor 11. Otra característica que me llamó la atención, esta la homoiconicidad (si, un poco largo, en inglés “homoiconic”). Esto quiere decir algo así como “el código también es un dato”; en algún sentido esto facilita que los programas creados en Clojure generen fácilmente código ejecutable.

Por ultimo, una recomendación personal para los que nunca programaron en un lenguaje funcional antes (como yo…)  empiecen por entender como se usan los paréntesis en el código:

Si en C# una función es: void MiMetodo(string miValor) { … } y se llama MiMetodo(“Hola”)

En Clojure es (defn MiMetodo [mivalor] (…) ) y se llama (MiMetodo “Hola”)

A continuación les dejo una serie de links que me fueron útiles para introducirme a la programación funcional en Clojure:

Posted in Clojure, FIUBA, Programming | 1 Comment »

Introduccion a los Sistemas Distribuidos – Frame Relay y ATM

Posted by sebastiandurandeu on August 10, 2010

En esta serie de posts, voy a publicar algunos resumenes que tengo sobre temas de la materia Introducción a los Sistemas Distribuidos de FIUBA (el profesor es José Ignacio Alvarez Hamelin).

En este post incluyo los temas de Frame Relay y redes ATM.

Introducción

  • Frame Relay y ATM son switched communications network. La data es switcheada de nodo a nodo.
  • Dos modos: Circuit Switching vs Packet Swithcing
  • Frame Relay es un ejemplo de Packet Switching.
  • Una red puede ser connection-mode (virtual circuit) o connectionless-mode (datagram). En connection-mode se establece una conección logica entre el transmisor y el receptor. En connectionless-mode los paquetes son ruteados del origen al destino
  • IP es connection-less.
  • ATM sería como la evolución de Circuit + Packet.

Circuit Switched Networks

  • El canal de comunicación se establece previo al envio de datos y es dedicado. Una vez establecido no se puede usar para otra comunicación, entonces se desperdician recursos si el canal no se usa un 100%.
  • Los links entre nodos (puntos intermedios) tienen multiplexación. With circuit switching, time on a node-to-node link is preallocated using synchronous time-division multiplexing.
  • Redes telefónicas.

Packet Switched Networks

    • Buenas para conectar puntos lejanos. El objetivo es mejorar las limitaciones de las redes conmutadas de circuitos, aprovechando mejor los tiempos en los que la linea no se usa.
    • El data rate puede no ser constante como en Circuit Switched.
    • Data is transmitted in short packets.
    • Si el paquete es mas grande, se fragmenta. Cada nodo toma una decisión de switching.
    • Most packet-switched and frame relay networks carry non-real-time data traffic.
    • Approaches de ruteo:
      • Datagram (connectionless mode): Cada paquete es ruteado independientemente. Los paquetes tienen la dirección de destino. No se asegura el orden.
      • Virtual Circuit (connection mode): La ruta es fijada antes de establecer la comm. Cada paquete tiene un identificador de VC y en base a eso se rutea. No significa que hay un dedicated path.
  • clip_image001

X.25

  • Usa virtual circuits. Cada terminal puede establecer muchos circuitos virtuales con diferentes destinos.
  • Virtual Call (dinámico en cada comm) vs Permanent Virtual Circuit (fijo).
  • Mantiene un quality of service.
  • Hay chequeo de errores hop-by-hop. Baja velocidad.

Frame Relay (Virtual Circuit Packet-Switching)

  • Es la evolución de X.25. Originalmente pensado para ISDN.
  • TCP/IP puede correr sobre Frame Relay, no así sobre X.25.
  • X.25 is a reliable protocol, based on node-to-node automatic repeat request, while Frame Relay is a non-reliable protocol.
  • Elimina el overhead de corrección de errores y flow control de X.25 para hacer communicaciones mas rápidas.
  • As with X.25, frame relay supports multiple connections over a single link. In the case of frame relay, these are called data link connections, and each has a unique data link connection identifier (DLCI).
  • Anda bien para el tráfico en ráfagas.
  • Es mas barato que una conexión punto a punto. Corre sobre DS1.

ATM

    • Pensado para usarse en muchos contextos: LAN, WAN, etc. Hoy en dia solo se usa en WANs.
    • Pensado para transportar tanto voz como datos (rango de servicios / B-ISDN):
      • Telephone networks supports a single quality of service and is expensive to boot.
      • Internet supports no quality of service but is flexible and cheap.
    • La especificación quedó muy cara.
    • Usa FIBRA OPTICA.
    • La data se divide en fixes-size cells (53 bytes: 5 de header + 48 de datos). Las celdas se transmiten asincrónicamente. Su orden está garantizado. Las celdas son chicas para hacer switching rápido.
    • Toma mucho de frame relay. Es connection oriented, hay que establecer la comunicación antes de empezar a trasnmitir. Todas las cells usan el mismo camino.
    • Se reservan recursos. Puede transmitir muchos tipos de tráfico seteando end-to-end quality of service.
    • Las direcciones ATM tienen 20 bytes.
    • Es asincrónico!
    • Control Signaling: Es lo que se usa para establecer una conexión con otro nodo ATM, usando la ATM address. Se usa un Virtual Channel aparte.
      • Para comunicarse con un nodo remoto, un host debe solicitar a su switch local el establecimiento de una conexión con el destino. Estas conexiones pueden ser de dos naturalezas: Switched Virtual Circuits (SVC) o Permanent Virtual Circuits (PVC). (http://www.angelfire.com/wi/ociosonet/29.html)
      • En vez de usar la dirección origen y destino, se usan los VPI y los VCI.
    • Por el cable van varios Virtual Path (origen y destino fijos) que a su vez se dividen en varios virtual channels. To set up a virtual channel, there must first be a virtual path connection to the required destination node with sufficient available capacity to support the virtual channel, with the appropriate quality of service.
    • El VPI, junto con el VCI, se utiliza para identificar el próximo destino de una celda a medida que atraviesa una serie de switches ATM hasta llegar a su destino.
      • VCI (Virtual Channel Identifier)
      • VPI
    • La función del VPI es similar a la del DLCI en Frame Relay.
    • Puedo hacer ATM sobre SDH o SDH sobre ATM. ATM no especifica el medio de transmisión.

QoS

    • Traffic parameters can be negotiated between a user and the network for each VCC.
    • CBR: Constante. Videoconferencing, telephony services, and television broadcast. CBR can send cells at peak cell rate (PCR) at any time and for any duration.
      • PCR como la máxima
      • CDV
      • CTD
    • VBR: Entre un mínimo y un máximo. Modern Video Codecs. A veces se necesita mucho, a veces poco. Bandwidth for VBR applications varies within a specified range. Delay and delay variance requirements are not fully defined. Ejemplos: video-on-demand (VOD) and voice-over-IP (VoIP) – Comprimido!
      • PCR
      • SCR
      • MBS
      • Opcionales –> CDV / CTD
    • ABR: Solo un mínimo. The Available Bit Rate (ABR) Class of Service requires the use of flow control mechanisms for ensuring allocation of bandwidth on-demand for non-real-time, mission-critical applications. With ABR applications, guaranteed minimum transmission rates are specified for the duration of the connection. Ejemplos: LAN-to-LAN
      • PCR
      • MCR
    • UBR: Nada.Puede tardar todo lo que sea o perderse lo que sea. The Unspecified Bit Rate (UBR) Class of Service is equivalent to best-effort delivery in IP networks. Delay-tolerant UBR applications include Web browsing and IP transmissions.
      • PCR (solo para información, no asegura nada).
    • Parámetros
      • Peak cell rate (PCR): The peak cell rate is the maximum rate at which the source can transmit.
      • Cell-delay variation (CDV): Defines the jitter or variation in the delay that might be experienced by any particular cell.
      • Cell transfer delay (CTD): Defines the largest expected cell delay between entrance into and exit from the ATM network.
      • Sustainable cell rate (SCR): Average rate of cell generation rather than to a peak rate
      • Burst Tolerance (MBS – Maximum Burst Size?): Defines the amount of time or the duration at which the router sends at PCR.
      • Minimum Cell Rate (MCR): Rate at which a source router can always send.
      • Cell Loss Ratio (CLR)

AAL

    • Transforma los datos a ser enviados en celdas ATM. The ATM Adaptation Layer (AAL) facilitates cell segmentation and reassembly by dividing media streams received from upper protocol layers into 53-byte ATM cells for transmission over the physical link.
      • AAL Type 1 supports constant bit rate (CBR), synchronous, connection oriented traffic. Examples include T1 (DS1), E1, and x64 kbit/s emulation.
      • AAL Type 2 supports time-dependent Variable Bit Rate (VBR-RT) of connection-oriented, synchronous traffic. Examples include Voice over ATM. AAL2 is also widely used in wireless applications due to the capability of multiplexing voice packets from different users on a single ATM connection.
      • AAL Type 3/4 supports VBR, data traffic, connection-oriented, asynchronous traffic (e.g. X.25 data) or connectionless packet data (e.g. SMDS traffic) with an additional 4-byte header in the information payload of the cell. Examples include Frame Relay and X.25.
      • AAL Type 5 is similar to AAL 3/4 with a simplified information header scheme. This AAL assumes that the data is sequential from the end user and uses the Payload Type Indicator (PTI) bit to indicate the last cell in a transmission. Examples of services that use AAL 5 are classic IP over ATM, Ethernet Over ATM, SMDS, and LAN Emulation (LANE). AAL 5 is a widely used ATM adaptation layer protocol. This protocol was intended to provide a streamlined transport facility for higher-layer protocols that are connection oriented.
  • clip_image002

    (de ATM rincon del Vago)

ATM LAN

  • LANE (LAN Emulation): Emulación de LAN (LANE) ofrece interoperabilidad entre las redes heredadas y modo de transferencia asincrónica (ATM). Con LANE, redes Ethernet y Token Ring pueden interconexión con redes ATM.
  • The three primary LANE services are the LAN emulation configuration server (LECS), the LAN emulation server (LES), and the Broadcast and Unknown server (BUS). The LECS distributes configuration information to clients, allowing them to register on the network. The LES manages one or more Emulated LANs (ELANs); it is responsible for adding members to the ELAN, maintaining a list of all the ELAN’s members, and handling address resolution requests for the LANE clients. The BUS handles broadcast and multicast services.
  • Un mismo LECS sirve para varias ELANs.

  • Cuando se quiere establecer una conexión, el cliente (LEC) hace una consulta LANE ARP al LES y este le devuelve la dirección del destino. Al mismo tiempo, el LEC se conecta con el BUS y le manda los datos a este hasta que pueda establecer una conexión directa con el destino.
  • clip_image003

  • IP over ATM: La idea es la misma que LANE, usar un servidor central. Usa un servidor ATMARP para resolver las direcciones.
  • Pure ATM LAN:
  • clip_image004

Links

Posted in FIUBA, Networking | Leave a Comment »

The Business of Software de Michael Cusumano

Posted by sebastiandurandeu on June 10, 2010

Para la materia Calidad en el Desarrollo de Sistemas, de FIUBA, leí el libro The Business of Software, por Michael Cusumano. En este post voy a intentar dar una visión personal del libro Business of Software, incluyendo extractos de lo que yo creo son las ideas o enseñanzas más importantes del libro.

Como el título lo indica, el libro tiene la característica de ser muy orientado a la parte de negocio o económica del software y no tanto al aspecto operativo o conceptual, lo cual le da un toque distintivo frente a otros libros del área. Si bien el autor comparte “buenas prácticas”, según su experiencia, para llevar a cabo el desarrollo de software, estas siempre están acompañadas de ejemplos de empresas reales, con números concretos de cómo estas prácticas impactaron positiva o negativamente en las ganancias de las compañías.

Gran cantidad de ejemplos de experiencias del autor como consultor, permiten contrastar sus propuestas contra casos reales. Esto suma en la credibilidad de sus definiciones y propuestas y al mismo tiempo permite al lector tomar contacto con un resumen casos y experiencias reales de la industria que muchas veces escasean entre los estudiantes.

Ni bien comienza el libro llama la atención la afirmación de que “En la industria del software, es el negocio y no la tecnología el que determina el éxito o el fracaso”. Es común creer que lo difícil en el software es administrar los proyectos, diseñar arquitecturas para resolver problemas complejos con soluciones simples, entre otras cosas. Sin embargo el autor presenta la idea de que como vendemos, cobramos y publicitamos nuestros productos de software es muchas veces más importante que las anteriores problemáticas.

Creo que el capitulo central del libro es el capitulo dos. Una vez introducida la discusión del negocio del software con ejemplos de tres empresas, el autor identifica tres tipos de modelos de negocios que son utilizados por las empresas de software del mundo, los cuales están basado en la estrategia de venta de la empresa.

Primero está el modelo de negocio en base a la venta de licencias de software (“Products Company”). En este modelo una empresa desarrolla un producto de software estándar que después vende al público en general o a las empresas. Este es uno de los modelos de mayor rentabilidad porque una vez que el software ha sido desarrollado toda la venta incremental tiene costo muy bajo, es solo cuestión de “copiar un CD”. Esto último concepto, de grandes ganancias con poco trabajo de replicación se denomina en el libro, economías de escala. Es importante aclarar que solo se puede lograr esta ganancia con un producto fuerte (“best-seller” o “killer app”) de grandes ventas, como puede ser Microsoft Office o Microsoft Windows. La gran desventaja de este modelo es que es muy sensible al mercado, en tiempos económicos favorables las empresas están dispuestas a invertir en software nuevo y las ganancias pueden ser altas. Por el contrario en tiempos desfavorables, las ganancias pueden decaer notablemente por la falta de nuevos clientes.

Por el otro extremo, está el modelo de negocio en base a los contratos de servicios (“Services Companies”). Aquí el objetivo es vender, desde productos a la medida de los clientes hasta mantenimiento o adaptación de sistemas existentes. Este modelo tiene la ventaja que al trabajar con contratos a largo plazo y clientes cautivos, permite generar un flujo de ganancias continuo y ser menos susceptible a las altas y bajas del mercado. La desventaja es que el costo de brindar este servicio es sumamente alto porque es muy intensivo en mano de obra especializada, con lo cual los márgenes de ganancias no son tan altos como en el caso de la orientación a productos.

Finalmente aparecen los modelos híbridos, donde la empresa genera ingresos por venta de licencias de productos y también por venta de servicios para adaptar estos productos a las necesidades de cada cliente. El autor argumenta que a través del tiempo, la mayor parte de las empresas orientadas a productos tienden a evolucionar en empresas hibridas (o hasta en empresas orientadas a servicios) a medida que transcurre el tiempo y los productos que venden se vuelven mucho más corrientes y por ende deben bajar los precios de las licencias (“commodities”). El autor propone a este como el modelo más estable en cuanto a su capacidad de generar ganancias y sobrevivir a las altas y bajas del mercado.

El siguiente diagrama intenta resumir lo explicado anteriormente:

image

Me resultó bastante enriquecedora la sección del libro en la que el autor hace un repaso de la cambiante historia de la industria del software. Es interesante repasar el papel central de IBM en la industria y cómo fue que se realizó la transición desde vender sistemas de plataforma (“system software”) totalmente acoplados (“bundled”) al hardware subyacente, hasta vender software en productos empaquetados.

Creo que el libro está muy orientado a los “software entrepreneurs”, es decir personas que quieren instalar su propio negocio de software y no quedar en bancarrota en el camino. Más precisamente el capitulo cinco, lista una serie de recomendaciones del autor de que decisiones se deben tomar al momento de iniciarse en el negocio del software, cómo conseguir inversiones, como planificar el crecimiento, etc. Y para no dejar cabos sueltos, en el capítulo 6 se analizan 10 casos de “software start-ups” o empresas que se iniciaron en el negocio del software con las que el autor tuvo alguna relación.

Definitivamente el libro no está orientado a programadores, ni tampoco, creo yo, a líderes de proyecto o gerentes de nivel medio de empresas ya instauradas, ya que muy probablemente la problemática que presenta no está asociada a las tareas o inconvenientes diarios de estos profesionales. Esto no quita que el gran valor del contenido del libro, que nos permite “abrir la cabeza” hacia “otra realidad” del software que probablemente muchos de nosotros no vivimos día a día.

Lamentablemente, los números que el autor presenta sobre emprendimientos de software, son sinceramente bastante desalentadores: se cita un estudio en el cual solo 6 empresas de 1 millón que se crean, llegan a ser exitosas y cotizarse públicamente a través de acciones. De todas formas, casos exitosos hay y muchos y nadie dice que convertirse en una empresa multimillonaria como IBM, Microsoft o Accenture, es la única forma de ser exitoso, ya que hay puntos intermedios más modestos que también pueden dar ganancia y reconocimiento a sus fundadores. El autor dice, “no se puede tener éxito sin probar”.

Finalmente, con respecto a mi experiencia personal con la lectura, al iniciar la misma, tuve algunas complicaciones para entender completamente las ideas presentadas por al gran cantidad de términos y expresiones económicas que libro usa. El autor comienza el libro con gran cantidad de ejemplos de los resultados de los balances de compañías de software, con muchos números y porcentajes “duros” de ganancias y pérdidas. A medida que el libro avanza, los términos y ejemplos se van haciendo más familiares y la lectura se volvió más amena.

Debido a que el autor está muy en contacto con la compañía Microsoft (también escribió otro libro más específico sobre Microsoft, llamado “Microsoft Secrets”) constantemente a lo largo del libro se citan ejemplos de prácticas de esta empresa. Me atrajeron bastantes estos ejemplos, que permiten entender más sobre las prácticas, algunas buenas y otras no tanto, que llevaron a Microsoft a ser una de las más grandes, sino la más grande, empresa de software del mundo.

Otro aspecto que me resultó interesante del libro es el análisis de las características particulares industrias del software en cada parte del mundo, haciendo foco en tres o cuatro regiones: India, Japón, Estados Unidos y Europa. El autor en base a sus experiencias como consultor, y a otros trabajos de investigación propios, tiene la capacidad de mostrar las diferencias entre estas regiones tanto desde recursos humanos, como de prácticas especificas de administración de proyectos, etc. Me llamó la atención notablemente, los halagos del autor hacia la industria India del software; si bien conocía del alto desarrollo de la misma, no estaba al tanto de la alta calidad de sus empresas..

Concluyendo, lamentablemente, el libro data del año 2003, lo cual hace que temas como la Web 2.0, las redes sociales o la crisis estadounidense de 2008-2009, que tuvo fuerte impacto en la industria del software, no estén dentro de los ejemplos cubiertos por el libro. Sería muy interesante tener no solo la visión del autor sobre estos últimos años de la industria del software, sino también números concretos de la evolución (¿o porque no involución?) de la industria en este último período. Otra desventaja, también probablemente debida al año de publicación del libro, es que dentro de las empresas y casos de éxito de la industria analizados, en ningún momento se nombra a Google.

Glosario y Referencias

Estos son algunos términos o referencias particulares que fueron apareciendo a lo largo del libro que no conocía y me pareció interesante saber más al respecto:

  • Crossing the chasm: Siendo “chasm” algo así como cañón o risco, es un término basado en un libro de Geoffrey A. Moore y relacionado al ciclo de adopción de nuevas tecnologías por él mercado. Implica que hay un salto importante entre los clientes con preponderancia a adoptar nuevas tecnologías (Early Adopters) y el mercado masivo (Early Majority).
  • Whole product solutions: En marketing, consiste en un producto genérico (core product) rodeado de una serie de aditamentos, muchas veces prescindibles, que impulsan a los clientes a comprar el producto. En nuestro caso, el “core product” vendría a ser el producto de software y los aditamentos, la customización y soporte necesarios para adaptar el producto a un cliente en particular.
  • Catch-22: O Trampa 22, es una sátira antibelicista de historia ficción escrita por Joseph Heller y publicada en 1961. En este libro el autor presenta una paradoja circular. Se narra la historia de un piloto estadounidense en la Segunda Guerra Mundial que trata de evitar entrar en combate haciéndose pasar por loco. Paradójicamente, el artículo 22 del reglamento establece que nadie en su sano juicio querría pilotar un bombardero en semejantes circunstancias, de modo que su alegación demuestra en realidad que está cuerdo y que debe seguir pilotando.
  • Porter’s five forces: El Análisis Porter de las cinco fuerzas es un modelo estratégico elaborado por el economista y profesor de la Harvard Business School Michael Porter en 1979. Las 5 Fuerzas de Porter es un modelo que permite analizar cualquier industria en términos de rentabilidad. El autor nombre esta teoría como una base, entre otras, para su análisis del negocio del software. Las 5 fuerzas son:
    • Poder de negociación de los Compradores o Clientes
    • Poder de negociación de los Proveedores o Vendedores
    • Amenaza de nuevos entrantes
    • Amenaza de productos sustitutivos
    • Rivalidad entre los competidores
  • Venture Capital: El capital riesgo consiste en realizar inversiones a empresas nuevas de alto riesgo en cuanto al retorno de la inversión, que al mismo tiempo pueden generar altas ganancias en el caso de éxito.
  • IPO (Initial Public Offering): Cuando una empresa pone sus acciones a la venta publicamente por primera vez. El objectivo es incorporar capital a la empresa para posibilitar un mayor crecimiento.
  • Mosaic Web Browser: Mosaic es considerado el primer navegador Web. Su construcción fue dirigida por el fundador de Netscape, Marc Andreessen.
  • Unbundling: El autor utiliza este término denominando la separación entre vender software solo (“unbundled”) y venderlo acoplado al hardware subyacente (“bundled”).

Posted in Business, FIUBA, Libros | 2 Comments »

Simulación – FIUBA

Posted by sebastiandurandeu on June 28, 2009

Comparto la “referencia” del lenguaje GPSS que use para la materia Simulación (75.26).

Se puede bajar desde:
https://sebastiandurandeu.files.wordpress.com/2008/01/referenciagpss.doc

La versión original en la que esta basado es Cartilla.doc (Grupo Yahoo sistemas_fi_uba).

Posted in FIUBA, GPSS | Leave a Comment »

Analisis de la Información – FIUBA

Posted by sebastiandurandeu on August 7, 2008

Esto es una resumen de varios temas de la materia Analisis de la Información (75.09) de la Facultad de Ingeniería de la UBA.

UML – Modelo Estructural

Modeling

A good model includes those elements that have broad effect and omits those minor elements that are not relevant to the given level of abstraction.

We build models so that we can better understand the system we are developing:

  • Models help us to visualize a system as it is or as we want it to be.
  • Models permit us to specify the structure or behavior of a system.
  • Models give us a template that guides us in constructing a system.
  • Models document the decisions we have made.

We build models of complex systems because we cannot comprehend such a system in its entirety.

Modeling allow us to focus on only one aspect at a time –> “Divide and conquer”

All models simplify reality; the trick is to be sure that your simplifications don’t mask any important details.

UML: using a common language for software modeling.

Classes Responsibilities

You don’t want any one class to be too big or too small. Each class should do one thing well.

  • If you abstract classes that are too big, you’ll find that your models are hard to change and are not very reusable.
  • If you abstract classes that are too small, you’ll end up with many more abstractions than you can reasonably manage or understand.

Diagrama de clases

  • No esta mal agregar un identificador a las clases.
  • El rombo de asociación o agregación va en el contenedor.
  • Composición: “Es parte de”. Si elimino el contenedor no tiene sentido las partes.
  • Responsabilidad de una clase: Es un contrato o una obligación que debe cumplir una clase. Una clase debe tener una responsabilidad pero no muchas.

UML – Modelo Dinámico

Diagrama de Colaboración = Communication Diagram

Sequence Diagrams + Communication Diagrams = Interaction Diagrams

Interaction: An interaction goes further by introducing a dynamic sequence of messages that may pass along the links that connect these objects.

Diagrama de Secuencia

En el diagrama de secuencia, sobre la flecha va el nombre del método del objeto destinatario. Si A le manda un mensaje a B sobre la flecha va B.Mensaje().

La línea de vida se corta si el objeto se destruye.

The focus of control is a tall, thin rectangle that shows the period of time during which an object is performing an action, either directly or through a subordinate procedure.

Diagrama de Secuencia vs Diagrama de Colaboración

Because they both derive from the same information in the UML’s metamodel, sequence diagrams and communication diagrams are semantically equivalent. As a result, you can take a diagram in one form and convert it to the other without any loss of information, as you can see in the previous two figures, which are semantically equivalent.

  • To model flows of control by time ordering: Here you’ll use sequence diagrams.
  • To model flows of control by organization: Here you’ll use communication diagrams. Modeling a flow of control by organization emphasizes the structural relationships among the instances in the interaction, along which messages may be passed.

Lo que sigue es un ejemplo de loop (pide el password de una a tres veces) , de ejecución opcional (si el password fue valido) y de ejecución en paralelo (par). Parallel really means that two actions are uncoordinated and can happen in any order.

image

Sub- Modelos de UML

  • Modelo de Casos de Uso (Dinámico):
    • Diagrama de casos de uso: Organiza los comportamientos del sistema. Representa un conjunto de casos de uso y actores y sus relaciones.
  • Modelo de Objetos (estático) :
    • Diagrama de clases:
    • Diagrama de objetos: Modela las instancias de los elementos contenidos en el diagrama de clases. Muestra un conjunto de objetos y sus relaciones en un momento concreto.
  • Modelo de Interacción entre Objetos:
    • Diagrama de secuencia: Destaca el flujo de interacción entre objetos. Un diagrama de actividades muestra las operaciones que se pasan entre los objetos. Se pueden usar como diagramas de flujo para modelas operaciones.
    • Diagrama de colaboración:
  • Modelo de Estado de Objetos (Dinámico):
    • Diagrama de transición de estado de objetos: Representa una máquina de estados. Muestra las secuencias de estados por las que pasa un objeto a lo largo de su vida en respuesta a eventos, junto con sus respuestas a esos eventos.
  • Modelos de Negocio (Dinámico): Muestra el flujo de actividades en un sistema.
    • Diagrama de actividades: Destaca el flujo de control de actividades.
  • Modelo de Componentes (Estático): Muestra la organización y las dependencias entre un conjunto de componentes (Un componente = uno o mas clases). Los componentes son las cosas físicas que residen en un nodo: ejecutables, bibliotecas, tablas, archivos y documentos.
  • Modelos de Despliegue (Estático): Muestra la configuración de nodos de procesamiento en tiempo de ejecución y los componentes que residen en ellos. Un nodo corre uno o mas componentes.

Use Cases

Writing Effective Use Cases (Resumen Libro)

A use case need not be the best to be useful.

A use case captures a contract between the stakeholders of a system about its behaviour.

A well-written use case is easy to read. It consists of senteces written in only one grammatical form -a simple action step- in which an actor achieves a result or passes information to another actor. Learning to read a use case should not take more than a few minutes.

Business process people write business use cases to describe the operation of their business, while a software development team writes system use cases for their requirements.

A use case valid in one project might not be valid in another project.

Use cases reveal user goal the system will support.

In one use case:

  • All the interaction relate to the same goal of the same primary actor.
  • The use case starts at the triggering event and continues until de goal is delivered or abandoned, and the system completes its responsibilities with respect to the interaction.

A step in a use case can be drilled down to another use case.

Use case brief: Is a two-to-six sentence description of use case behavior, mentioning the actors, the goals an only the most significant activity and failures.

An actor might be a person, a company or organization, a computer program or a computer system- hardware, software or both.

Relations between use cases:

  • <<include>>: One use case refers or calls another.
  • <<extends>: Create extension use cases only when you need to, because they are harder for people to understand and mantain. Two Situations:
      • Many asynchronous or interrupting services the user might use, which should not disturb the use case. Example:Edit document –> Check Spelling –> Change template–> Find synonym
      • Writting additions to locked requirements.

Supporting Actors (or secondary actors): A supporting actor in a use case is an external actor that provides a services to the system under design. These are sets of actors that support the use cases provided by the system and those that support the system itself.

Actions of supporting actors involve to provide additional information or take some decisions.

An actor can be primary in one use case and supporting in another.

Primary actor: The primary actors are the ones for whom the system is built; they are the ones to whom the system provides sufficient economic value to warrant its construction. It is both necessary and correct that we should concentrate our efforts primarily on these actors and the users that will take on these roles.

When writing use cases: KEEP THE GOAL IN MIND.

Common mistakes:

– Avoid a use case where every statement is accomplished by the actor

– Customer enters card and PIN

– customer enters “Withdrawal” and amount.

– Customer takes cash, card and receipt.

– Avoid detailing user interfaces in the use case.

– Remember every use case must show the primary actor actions.

– Remember always naming who is doing the action, avoiding passive voice.

Use Cases Modeling (Resumen Libro)

We don’t consider the operating system, database, or other utilities as actors. Although we certainly make use of their capabilities, we are not required by the system to use them in specific ways at specific times.

A use case is focused on what the system must do, whereas code is an expression of how the system will do those things.

Prototypes: As the saying goes, a picture is worth a thousand words. If that’s true, a prototype is invaluable. Use prototypes to describe the user interface, leaving the use cases to describe what happens behind the screens.

The whole point of a use case is to capture a description of something that the system must do. It is an expression of a desired behavior of the system. The system must behave that way no matter how it is designed and implemented.

Make sure that each use case provides the user of the system with something of value.

Glossary: Use cases often contain a lot of information that can be better presented in other ways. Using a glossary of terms is one way to present necessary information that can otherwise be distracting to the reader.

Every use case has two exits: succed or fail.

Sub-flujos / Flujos Alternativos

  • “Named” Subflows: Sections that perform important behaviors but that are not essential to understanding the basic flow of events. Ej. Perform Authenticate Customer.
  • “Alternative” flows: Flows of events that occur when something other than the normal course of events has occurred.

Rational Unified Process

Esto es un resumen de todo lo que se da en la teórica sobre RUP.

Mejores prácticas para el desarrollo de software.

  • Proceso iterativo e incremental.
  • Dirigido por casos de uso
  • Arquitectura basada en componentes (reusabilidad).
  • Modelización visual
  • Gestión del cambio
  • Verificación de calidad

Contribución del RUP a las buenas prácticas

Iterativo e Incremental

  • 1 ciclo compuesto de distintas fases:
    • Inicio
    • Elaboración
    • Construcción
    • Transición
  • Cada una de estas fases tiene mas de una iteración. En cada una de las iteraciones hay diferentes disciplinas en las que se gasta mas o menos esfuerzo dependiendo de la fase en la que se esta.
    • Captura de requisitos
    • Análisis
    • Diseño
    • Implantación
    • Pruebas y Despliegue
  • Además de esto hay componentes de soporte del proceso:
    • Gestión de cambios: Trackear requerimientos de cambio. Versionado.
    • Administración de proyecto: Risk Managment. Monitoring process.
    • Gestión de ambiente: Preparación de ambiente de desarrollo (procesos y herramientas necesarios para el desarrollo).

Matriz de Esfuezo

Define el esfuerzo dedicado a cada disciplina en cada fase.

clip_image001[4]

Dirigido por casos de uso

Los casos de uso se utilizan a lo largo de todo el proceso. Los casos de uso son una buena forma de capturar requerimientos y guiar la implementación y las pruebas. La arquitectura del sistema y los casos de uso maduran conforme avanza el ciclo de vida.

clip_image002

  • En la captura de requisitos: Los casos de uso se unan para capturar y validar los requerimientos.
  • En análisis y diseño y en implantación: Se implementan los casos de uso.
  • En las pruebas: Se realizan las pruebas que verifiquen el cumplimiento de los casos de uso.

Arquitectura basada en componentes

Se trata de diseñar una arquitectura base ejecutable en forma temprana.

Arquitectura base ejecutable

  • Flexible
  • Fácil de modificar
  • Promover la reutilización de componentes

RUP apoya el desarrollo basado en componentes, tanto nuevos como preexistentes.

Modelización visual

Utilización intensiva de UML.

Gestión del Cambio

Los cambios pueden ser de requisitos o de funcionalidades. Los cambios son inevitables.

Como gestionar cambios?

  • Evaluación: Son realmente necesarios? Cual es su impacto?
  • Rastreo y monitoreo.

RUP provee herramientas para controlar, rastrear y monitorizar los cambios dentro del proceso de desarrollo.

Verificación de la calidad

RUP provee herramientas para planificar, diseñar, implementar, ejecutar y evaluar pruebas que verifiquen la calidad del desarrollo. De esta forma vemos que la calidad forma parte del proceso de desarrollo y no es responsabilidad de un grupo separado.

  • Funcionalidad
  • Rendimiento
  • Confiabilidad.

Matriz de Hitos y Productos de Cada Fase

clip_image003

clip_image004

Caso de Negocio: The Business Case provides the necessary information from a business standpoint to determine whether or not this project is worth investing in. For a commercial software product, the Business Case should include a set of assumptions about the project and the order of magnitude return on investment (ROI) if those assumptions are true. For example, the ROI will be a magnitude of five if completed in one year, two if completed in two years, and a negative number after that. These assumptions are checked again at the end of the Elaboration phase, when the scope and plan are defined with more accuracy.

RUP como Proceso de Desarrollo de software

Define:

  • Quien hace que cosa?
  • Que hace?
  • Como lo hace?
  • Cuando lo hace?

Sobre el Quien RUP define tres tipos de elementos:

  • Trabajador: define el comportamiento y las responsabilidades de un individuo.
  • Actividad: A unit of work in the RUP that a role may be asked to perform. An activity may be decomposed in steps. Activities produce or modify artifacts.
  • Artefacto: Artifacts are either final or intermediate work products that are produced and used during a project. Artifacts are used to capture and convey project information.

clip_image001[6]

  • Trabajador (Worker) :
    • Comportamiento –> Rol: A definition of the behavior and responsibilities of an individual, or a set of individuals working together as a team, within the context of a software engineering organization.
      • Analista
      • Diseñador
      • Ing. Pruebas
    • Responsabilidad: Actividad que va a realizar la persona, que será responsable de una serie de artefactos.
  • Actividad: Es una unidad de trabajo que se asigna a un determinado trabajador. No debería durar menos de dos horas y mas de veinte dias. Debe involucrar un solo trabajador y pocos artefactos. Ejemplos:
    • Planificar una iteración
    • Encontrar actores y casos de uso
    • Ejecutar pruebas unitarias
    • Ejecutar pruebas de performance
    • Diseñar casos de uso
  • Artefactos: Elementos de información producidos, modificados o utilizados durante el proceso. Son el resultado de actividades y utilizados además como inputs a otras actividades. Ejemplos:
    • Modelos: Modelo de caso de uso. Modelo de objetos.
    • Elemento de un modelo: Caso de uso. Clase.
    • Documentos: Caso de negocio. Documento de arquitectura del sistema.
    • En etapa de construcción: Código Fuente. Código ejecutable.

Matriz de Asignaciones

clip_image002[4]

Análisis Estructurado

El modelo esencial supone que se tiene disponible una tecnología perfecta y que se puede obtener fácilmente. (Yourdon p.358) Un modelo se tiene que componer de gráficos y documentos de texto. Uno o mas gáficos debieran ser el documento primario al que se dirige el usuario para poder entender el sistema; los documentos textuales debieran servir de material de referencia para consultar en caso de necesidad (Yourdon p.152)

Modelo Ambiental

Objetivo

Ejemplo:

clip_image001

Diagrama de Contexto

Muestra:

  • Las personas, organizaciones y sistemas con los que se comunica el sistema.
  • Los datos que el sistema recibe del mundo exterior.
  • Los datos que se envían al mundo exterior.
  • Los almacenes de datos externos al sistema.
  • A veces conviene dibujar a los objetos externos mas de una vez.

Lista de Eventos

En todo evento va a ocurrir un estímulo y una respuesta.

Eventos

  • Externos: Entidad Externa + Verbo + Objeto
  • Temporales
    • Tipo 1: Período + Verbo + Objeto (Nadie espera lo que se emite)
    • Tipo 2: Período + Ent. Externa + Verbo + Objeto (La entidad externa solicita el objeto)

Lista de Estímulos y Respuestas

  • Los almacenamientos van en plural.
  • Usar:
    • Mensualmente vs Todos los meses

    Modelo de Comportamiento

    Modelo de Procesos

  • DFD: Modelo las funciones que lleva a cabo un sistema. Evitar los verbos: Hacer, Manejar y Procesar. Son verbos muy genéricos.
  • Diagrama de Transición de estados: Modela el comportamiento dependiente del tiempo de un sistema.

    Modelo de Datos

  • Diccionario de datos: Un listado organizado de todos los datos pertenecientes al sistema para tener un entendimiento común de:

    • Todas las entradas, salidas y almacenes y cálculos intermedios del sistema.
    • Relaciones entre almacenes del DER.
    • () –> Se usa para un dato opcional.

    DER: Describe la distribución de datos almacenados en un sistema.

    • Los tipos de objeto van en singular.
    • Puede haber relaciones entre el mismo tipo de objeto (Relación reflexiva. Ej. Curso correlativo de curso).
    • Cada instancia tiene que poder identificarse en forma univoca.
    • La relación entre tipo de datos es algo que debe ser recordado por el sistema.
    • Objetos no instanciables (unicos en todo el sistema) no van en el DER.
    • Herencia:

    clip_image002[1]

    El nombre de una asociación solo va si la asociación es pura.

    Bibliografia

    Posted in FIUBA, RUP, UML | 2 Comments »

    Estructura de las Organizaciones – FIUBA

    Posted by sebastiandurandeu on January 17, 2008

    Esto es un resumen mio de la materia Estructura de las Organizaciones de la carrera Ingeniería en Informática de la Universidad de Buenos Aires. Espero le sirva a alguien que la curse.

    Recomiendo usar el libro:

    Producción de Ricardo F. Solanas, Ediciones Interoceánicas.

    Que si bien no esta en la bibliografía oficial de ahí sacan muchas cosas los docentes de la práctica.

    Ahi va el resumen:

    Evolución del pensamiento administrativo

    Neoclasicos

    – Contemporáneos de la escuela del comportamiento humano
    – Su finalidad era adaptar y ajustar los esquemas clásicos a las nuevas exigencias del contexto sin modificar
    sustancialmente los modelos clásicos (mas tecnologia, organizaciones mas grandes / hasta 2da guerra mundial)
    – Reformulan algunos postulados básicos.
    – Desarrollan el modelo ACME

    Teoría de la organización

    – Pasada la 2da guerra mundial
    – Critican los principios de la administración
    – Reemplaza el concepto de hombre económico por hombre administrativo
    – Agrega a la organización informal a la teoría

    Sociología industrial

    – Grupo como entidad fundamental
    – Se analizan los distintos tipos de jefes- Teoría de la contingencia
    – La palabra contingencia: “toda variable externa,
    característica ambiental, factor circundante o fuerza influyente que afecta el diseño efectivo
    de la organización y a su comportamiento de forma, en principio no controlable directamente”,
    por medio de una relación si (causa)… entonces (efecto).
    – A diferencia del resto de teorías organizacionales, la contingencial centra su foco de atención en el ambiente
    externo de la empresa, dando prioridad a lo que ocurre fuera de la organización antes de indagar en los elementos internos de la estructura organizacional. Dicho enfoque busca un equilibrio entreambos contextos, donde la organización busca obtener el mayor beneficio de sus circunstancias ambientales para garantizar su éxito como empresa.

    Sociedades comerciales

    Soc. de hecho: Los socios responden con todo su patrimonio. La sociedad no puede ser dueña de bienes.

    Teoría de Sistemas

    – Concepto de sistema: conjunto organizado, partes interrelacionadas y ordenadas, objetivo común
    – Funciones de un sistema
    – Caracteristicas de un sistema

    Diseño Organizativo

    Seleccionar la mejor estructura para mi empresa.
    – Mecanicista
    – Organico
    – Reingenieria: La reconcepción fundamental y el rediseño radical de los procesos de negocios para
    lograr mejoras dramáticas en medidas de desempeño tales como en costos, calidad, servicio y rapidez

    Organizar

    Es agrupar actividades, delegar autoridad, asignar funciones, responsabilidades y establecer un sistema de comunicaciones sobre el grupo de personas que componen la empresa.
    Tratar de hacer andar la fábrica con la menor cantidad de gente/conflictos.

    Sus fundamentos son:
    – Division del trabajo: Optimizar la asignación de tareas.
    – Departamentalizacion: Agrupar tareas afines.
    – Jerarquía
    – Coordinación

    Tipos de Organización

    Lineal o militar

    Las decisiones se concentran en una sola persona. Esta asigna y distribuye el trabajo.
    Muy claro y simple. Muy poco flexible.

    Funcional o de taylor

    Mucha espacialización pero poca vision global.
    A veces esta funcionalizada una función en la empresa. Si es funcional tiene autoridad. El staff no tiene autoridad.

    Mixta (lineo-funcional)

    Se mantiene la especialización pero se logra la unidad de mando.

    De linea y staff
    Estructura con comité
    Estructura por proyecto

    Un individuo depende de dos personas. Del gerente del área y del director de proyecto. La división es para algunos
    proyectos en particular.

    Estructura Autónoma

    Los participantes del proyecto no dependen mas del director funcional.

    Estructura Matricial

    Toda la empresa es por proyectos.

    Departamentalización

    Es agrupar actividades en unidades o sectores en los cuales se delega autoridad y tienen responsabilidad antes sus
    superiores de llevar a cabo y cumplir los objetivos planteados.

    – Por funciones (clasica)
    – Por producto
    – Por separación territorial
    – Por conjunto de procesos (gaseosas vs aguas minerales)

    Funcionalizacion (= división del trabajo)

    – hacia abajo
    – hacia afuera

    Manual de funciones

    Es un registro escrito de la organización FORMAL de la empresa donde se detallan aspectos operativos y detalles
    de prácticas estándar que ayudan a una mejor dirección.

    Dirección

    – Ciclo de dirección (ver)
    – Principios de la dirección (ver)
    – Ppio. de unidad de mando (importante) (ver)

    Tablero de control

    Una síntesis de la información más reelevante de la producción preparada con el propósito de que el nivel
    superior de la organización cuenten con los elemento de jucion necesarios para tomar decisiones.

    Producción

    Es la transformación de insumos en productos.

    Hoy se tiende a la desintegración vertical (de la cadena de producción) / horizontal ( de los servicios)
    Cada uno especialista en los suyo.

    Spin-off o empresas derivadas

    Tipos de producción
    Por pedido (intermitente)

    – Mas flexible
    – Personal mas capacitado

    Por stock (continua)

    – Personal menos calificado
    – Estructura mas fija
    – Ventas menos capacitados

    Estándares

    Cualquier criterio o modelo establecido aceptado contra el cual se pueden realizar comparaciones. Puede referirse a cualquier aspecto de la actividad.

    Cluster de empresas:

    Un cluster en el mundo industrial (o cluster industrial) es una concentración de empresas relacionadas entre sí, en una zona geográfica relativamente definida, de modo de conformar en sí misma un polo productivo especializado con ventajas competitivas. (ej Sillicon Valley)

    Abastecimiento y Compras (proveedores)

    Objetivos

    – Cantidad pactada
    – lugar indicado
    – momento justo
    – mínimo costo
    – calidad especificada

    Curva ABC

    El 20% de las materias primas tiene el 80% del valor del producto final.

    Lo que ocurre con los proveedores e mis proveedores también me afecta. Ir bien hacia atrás en la cadena.

    Desarrollo de proveedores (integración vertical hacia atrás virtual)

    Pocos proveedores con relación mas duradera en el tiempo. Compromiso y apoyo mutuo.
    El proveedor me garantiza la calidad. Proveer mucha información. Me ahorro la constante negociación.

    Costo global de abastecimiento

    Precio de adquisición + costo de gestión + costo de la no calidad

    Recursos Humanos

    Área de servicio a las áreas productivas de vital importancia.

    Mejorar la calidad de vida laboral

    Motivación

    Hacer que un empleado actúe de determinada manera.
    Formas de motivación: económicas y no tanto.

    Reclutamiento

    -Planeamiento de recursos humanos.
    – Planeamiento de la estructura organizacional
    – Definición de RRHH cuanti y cualitativamente
    – Comparar entre previstos y disponibles
    – Definición de necesidades de ingresantes
    – Formas de reclutamiento

    Capacitación

    Mejorar las aptitudes de los empleados. Dificil evaluar el costo-beneficio.

    Remuneraciones

    – Condicionado por jerarquía, mérito, antigüedad, importancia de su área
    – Hay remuneraciones financieras, beneficios financieros indirectos, compensaciones no financieras.

    Evaluación del desempeño

    – Formal: Periódicamente, metodología preestablecida. Evaluan objetivos, factores objetivos y factores subjetivos.
    – Informal: Forma cotidiana.

    Recursos de una empresa

    Mano de obra (capital humano y mas importante)
    Materia Prima
    Dinero
    Conocimiento
    Instalaciones
    Organización

    Logística

    La administración del flujo de materiales y su información asociada, desde el abastecimiento hasta la distribución física, esto es, la cadena que va desde el proveedor al cliente.

    El proceso de gestionar todas las requeridas para mover estrategicamente materia prima , piezas y productos terminados desde los proveedores, entre instalaciones dentro de la empresa, y hacia los consumidores de forma que se consiga llegar cuando se necesita y con el mínimo coste integral. Incluye tambien la prestación de los servicios de planta como agua, gas, electricidad, etc.

    Logistics is the art of managing the supply chain and science of managing and controlling the flow of goods, information and other resources like energy and people between the point of origin and the point of consumption in order to meet customers’ requirements. It involves the integration of information, transportation, inventory, warehousing, material handling, and packaging.

    Ciclo de operaciones básicas de una empresa manufacturera (ver)

    Estructura Formal vs Estructura informal

    Informal: Canales de comunicación no explicitados.

    “No puede existir una organización informal si no existe una organización formal previa”

    Alianza Estrategica

    Es una relación bilateral o multilateral caracterizada por el compromiso de dos o más compañías para llegar hasta un objetivo común.

    Controlar vs. Evaluar

    Controlar: Ver que hay un problema
    vs
    Evaluar: Ver el motivo del problema

    Elementos de un objetivo

    – Valor
    – Atributo
    – Escala
    – Horizonte de tiempo (plazo)

    Eficacia vs Eficiencia

    Eficacia (efectividad): Cumplir los objetivos
    vs
    Eficiencia: Lograr los objetivos con el menor uso de los recursos posibles.

    Sinergia

    La sinergia es la integración de elementos que da como resultado algo más grande que la simple suma
    de éstos, es decir, cuando dos o más elementos se unen sinérgicamente crean un resultado que aprovecha y maximiza
    las cualidades de cada uno de los elementos.
    Ejemplo:
    Los sistemas sociales: los cuales son siempre sinérgicos, un modelo de éstos es una escuela, ninguna de las partes
    de ésta produce aisladamente personas totalmente capacitadas para ser miembros activos de una sociedad…

    Staffing

    This refers to filling open position – either by hiring new employees or by reassigning persons already employed.

    Holístico

    Que tiene que ver con el todo.

    Autoridad vs Responsabilidad

    Autoridad: Facultad o derecho a actuar, decidir o exigir acción a otra persona.

    vs

    Responsabilidad: Es la obligación de obtener resultados y rendir cuenta de los deberes o funciones asignadas.

    “Asigno responsabilidad, otorgo autoridad”

    “La responsabilidad NO SE DELEGA, se ASIGNA.”

    “Si no se tiene la autoridad necesaria no puede cumplirse ninguna responsabilidad”

    Culpable vs Responsable (ver)

    Autoridad vs Poder

    La autoridad es formal, el poder no

    Organigrama

    Es la representación grafica de la estructura formal de la empresa.

    Organigrama ACME

    El esquema general ACME divide a la empresa en siete funciones:

    Producción
    Comercialización
    Finanzas y control
    Investigación y desarrollo
    Administración de personal
    Relaciones Externas
    Secretaría y Legales

    Organigrama básico de una empresa manufacturera

    Directorio arriba de todo (algunos miembros de la asociacion)
    Del directorio sale el gerente general (Director Ejecutivo / CEO – Chief Executive Officer) donde arracanca la sección ejecutiva.

    Planes y Estrategias

    – De mayor a menor detalle:

    Estrategia: Definen el rumbo de la organización, sus objetivos mas globales (a nivel dirección). A largo plazo.

    Táctica / Plan: Cursos de acción para lograr los objetivos deseados.
    Definición detallada de las estrategias.(departamentos)
    Decisiones de cursos de acción futuros. Que quiero hacer? a donde quiero llegar? Mas general.
    (parte de la táctica a nivel departamentos)

    Programa: Abarca períodos mas cortos. Asignación de recursos y sincronización de ops. (parte de la táctica a nivel sectorial)
    Detalle del plan. Que hago dia a dia?

    Lanzamiento: La orden de empezar a producir (capataces)

    “Las tácticas desarrollan los detalles acerca de como las estrategias serán implementadas.”
    “Cada estrategia puede dar nacimiento a numerosas tácticas”

    Calidad total

    Basada en el mejoramiento permanente. Consiste en alcanzar un desempeño de la mas alta calidad en todo lo que se hace en una
    organizacion, no solamente en el producto que se entrega al cliente. Todo el mundo tiene un cliente. Se pretende que todo lo que se hace en la
    empresa alcancen una calidad equiparable a la que se establecería si fueran prestados a terceros.

    Posted in FIUBA | Tagged: , , , , | 3 Comments »