A visão holística de uma empresa equivale a se ter uma "imagem única", sintética de todos os elementos da empresa, que normalmente podem ser relacionados a vi- sões parciais abrangendo sua estratégia, atividades, informações, recursos e orga- nização, assim como suas inter-relações. Essa divisão tomou como base as visões do CIM-OSA, discutido a seguir no item "Nova leitura da sigla CIM". Como recursos deve-se entender os recursos financeiros que a empresa utiliza, seus equipamentos de produção e de trabalho, os métodos e técnicas empregadas, hardware, software, etc.... O conceito de organização aqui empregado é mais abrangente do que o nor- malmente conhecido. Ele considera a estrutura organizacional e suas inter-relações, a sua cultura, as pessoas e sua qualificação, as formas de comunicação, assim como a capacidade de aprendizado da organização. Pensar a empresa como um conjunto de business processes é o que mais se aproxima de um formalismo para a obtenção da visão holística.

​

RACIOCINAR COM BASE EM BUSINESS

 

Allaire, da Xerox, divide os processos empresariais em 3 tipos [GAR95]:

-    processos de gerenciamento: com os quais a alta cúpula dirige a empresa, inte- rage com os funcionários, toma decisão e se comunica. Esses processos marcam o contexto organizacional da empresa e determinam o estilo de trabalho. Como exem- plos desse tipo de processo têm-se: gestão estratégica e definição de investimento a longo prazo.
-    business processes (BP): definidos abaixo e escopo deste capítulo. Como exemplos têm-se: desenvolvimento de produtos, comercialização de produtos, fabri- cação de produtos e atendimento ao cliente.
-    processo de trabalho: são os elementos dos BP e representam o aspecto operacional de como se realizam as atividades dos BPs.
 

Para que os BPs possam servir de referência para essas diversas abordagens e mesmo para a manufatura integrada, eles devem ser mapeados [BAR93]. A organi- zação inteira deve pensar em termos de BP [GAR95]. O mapa do BP é essencial como base de referência para discussões, a fim de apoiar a obtenção sistemática de uma a visão holística da empresa. No entanto, a visão holística é algo abstrato. Exis- te então uma dificuldade de representação do BP.

 

REPRESENTAÇÃO DE BUSINESS PROCESS

 

Uma adaptação da técnica SADT foi utilizada com sucesso em alguns casos prá- ticos, no mapeamento do BP [ROZ95a, TIB95]. Esta representação tem três níveis. No primeiro coloca-se uma representação analógica do business process. No se- gundo nível as atividades estão listadas dentro de caixas interligadas com flechas, que indicam as informações que entram e saem das atividades. Dentro de cada cai- xa são colocadas siglas que indicam os recursos utilizados na atividade correspon- dente, assim como a organização responsável pela sua realização. Com esses dois primeiros níveis monta-se um “pôster”, que fornece uma visão abrangente do BP (figura 8). Neste pôster estão também listados os significados das siglas de recursos e organização. No terceiro nível detalham-se as atividades, utilizando-se texto estru- turado, no qual o procedimento de uma caixa do segundo nível é documentado. Este nível pode servir de referência, ou mesmo estar em consonância com a ISO 9000.

​

Quando o BP torna-se completo, aumenta a dificuldade de se manipular o seu modelo, principalmente quando existirem visões complementares, por exemplo um MER (Modelo Entidade Relacionamento) para a representação da visão informação. Para apoiar essa manipulação existem hoje ferramentas computacionais disponíveis no mercado [ROZ95b].

 

Uma outra tecnologia disponível parece que pode ser o caminho para a criação de software no futuro. Essa tecnologia tem a sigla BPA (business process automa- tion) ou BPE (business process execution) e seu princípio está na automação de atividades específicas definidas em um BP resultante, por exemplo, de um trabalho de Reengenharia. O desenvolvimento desses building blocks de software específi- cos seria realizado com um ferramenta de desenvolvimento orientada por objeto  com grande produtividade e alto grau de abstração.

 

A homogênea parte do princípio que existem uma base de dados única para to- dos os aplicativos [PET92]. Isto é conseguido através de sistemas integrados, que contém teoricamente todos os aplicativos que uma empresa de manufatura necessi- taria. Esses sistemas são bem flexíveis, pois podem ser configurados para diversas alternativas. O problema maior desses sistemas integrados é o seu tempo e custo  de implantação. Hoje, no entanto já surgem sistemas integrados baseados na arqui- tetura cliente-servidor, com cliente Windows TM Assim, esses aplicativos podem fa- zer uso da tecnologia OLE (object link embebed), o que facilita a integração funcio- nal com outro aplicativo que trabalhe também com o padrão OLE. O mesmo aconte- ce no mundo UNIX com o padrão CORBA. Em futuro próximo aguarda-se que tanto um padrão único seja adotado para qualquer plataforma de hardware. O problema ainda fica na integração da base de dados, pois os modelos dos sistemas integrados normalmente fazem um uso extenso da integridade referencial, dificultando a troca on-line de dados com aplicativos não nativos no sistema integrado.

 

A integração heterogênea, como o próprio nome diz, preocupa-se em integrar sistemas distintos, desenvolvidos por fornecedores diferentes [PET92]. Ela toma como base um repositório de dados também conhecido como meta base de dados, que é uma espécie de dicionário de todos os dados que estão nas bases de dados de cada um dos aplicativos a serem integrados. A grande desvantagem aqui é o ar- mazenamento redundante de dados. Por utilizar sistemas diferentes pode acontecer que em um ambiente heterogêneo existe também uma redundância das funções ofe- recidas por dois aplicativos ou mais. Um exemplo de uma integração deste tipo pode ser visto no Ambiente de Engenharia Integrado desenvolvido pelo autor deste e que utiliza sistemas comercias [ROZ95a, TIB95]. Esse princípio de se trabalhar com me- ta base de dados pode também ser utilizado na integração de diversos building- blocks da tecnologia BPA.

 

A integração depende de dois fatores básicos: educação e metodologia.

 

A integração começa com educação, passa por educação e continua com educação. Utiliza-se aqui o significado amplo do termo educação, que se inicia fora das empresas e continua por toda a vida profissional do indivíduo.

 

A metodologia deve ser um frame de métodos, técnicas e ferramentas, que o indivíduo educado (ou grupo de indivíduos) pode acessar e utilizar conforme a sua necessidade específica.

 

PAPEL DA ENGENHARIA NA EMPRESA INTEGRADA

​

A visão departamentalista da empresa deve ser substituída pela visão por pro- cessos. No entanto, muitas empresas adotam essa nova filosofia até a última con- sequência obtendo resultados negativos.Criar um setor que só cuide do desenvolvimento de novos produtos pode ser um desvio da filosofia por processos. O desenvolvimento de produtos é essencialmente multidisciplinar. Corre-se o risco de se criar um nicho de especialistas, que em pouco tempo estarão ultrapassados.

O desenvolvimento de produtos deve ser realizados por time multifuncionais, composto por pessoas de diversas áreas, para exatamente poder unir os seus dife- rentes skills atualizados. Um departamento específico para desenvolvimento de pro- dutos poderia neste caso ser somente um catalizador e gerenciador deste processo. Um departamento de engenharia então dentro deste conceito deve ter sua com- petência bem aprimorada para gerenciar o processo de desenvolvimento de produ- tos, fornecendo “consultores internos” nas atividades mais técnicas, como por exemplo em cálculos estruturais, para diversos times. Além disso, outros tipos de consultores devem atuar como atores em outros processos.

​

ENGENHARIA SIMULTÂNEA NA EMPRESA INTEGRADA

​

Com base nos conceitos apresentados, pode-se definir Engenharia Simultânea como sendo a filosofia de atuação do business process no processo de desenvolvi- mento (ou alteração) de novos produtos, visando:

•    Um aumento de qualidade do produto, com foco no cliente;
•    Uma diminuição do ciclo de desenvolvimento e
•    Consequente diminuição de custos.

Esta filosofia toma como base na sinergia entre seus agentes, que devem traba- lhar em equipes multifuncionais, formadas por pessoas de diversas área da empre- sa. Esta equipe deve crescer e diminuir ao longo de sua existência, mantendo sem- pre um mesmo núcleo de pessoas, que acompanham o desenvolvimento. Durante algumas atividades deve fazer parte desta equipe clientes e fornecedores, quando se trabalhar no conceito de cadeia de suprimentos, conforme a posição da empresa dentro desta cadeia. Todo o trabalho desta equipe deve ser suportado por recursos, métodos e técnicas integradas, tais como: QFD, FMEA, Tagushi, etc.... Apesar da repetição, deve-se sempre enfatizar que o foco do trabalho deve estar concentrado nas necessidades do cliente.

Apesar de longa, essa definição poderia ainda ser considerada incompleta, pois, por exemplo, não citou a melhoria contínua e outros conceitos, que a tornariam mui- to mais extensa. Na figura 12 pode-se obter uma visualização gráfica desta defini- ção.
O importante aqui é ressaltar que todos os elementos da empresa envolvidos nesta definição (resumidamente agrupados neste trabalho em atividades, informa- ção, organização e recursos) devem estar “desenhados” no modelo do business process.

​

​

.