[11] ERP, Data Warehouse et al

Na última aula fomos presenteados com uma palestra extremamente interessante sobre ERP (Enterprise Resource Planning), ministrada pelo senhor Fábio Medeiros da MD Sistemas.

O Sr. Fábio é sócio da MD Sistemas, que se dedica à implantação de sistemas ERP (Sapiens da Senior Systems) em empresas de diferentes segmentos de negócios, e traçou um esboço abrangente com os propósitos, funcionalidades e limitações de um sistema ERP, além de discorrer sobre as peculiaridades e dificuldades para implantação do mesmo.

Sintetizando, um sistema ERP busca abrigar sob regras comuns todos os dados de interesse da empresa (administrativos, contábeis, de vendas, de produção, de compras, etc), interligando-os e buscando evitar desperdícios e esforços desnecessários, como a entrada repetida de um mesmo dado, a representação de um mesmo dado sob formas diferentes, e assim por diante. O objetivo é prover informações que auxiliem as decisões negociais de uma empresa de forma mais rápida, precisa, transparente e inteligível.

Em seguida a professora Renata introduziu o conceito de Data Warehousing (DW). Numa comparação cinematográfica, bancos de dados de sistemas ERP guardam os fotogramas dos eventos empresariais, enquanto o DW procura estruturar e guardar o filme inteiro. Isto se presta a estudos, projeções, acompanhamento de tendências, identificação de padrões, sendo poderoso auxiliar na definição de estratégias para os negócios. Guardando as devidas proporções, poderíamos dizer que um sistema ERP é ferramenta eminentemente tática e subsidiariamente estratégica, enquanto o DW é eminentemente estratégico (e subsidiariamente tático). Uma vez estruturados e armazenados, os dados ficam disponíveis para a aplicação de técnicas, métodos e ferramentas analíticos, como OLAP (OnLine Analytical Processing) e Data Mining.

E para finalizar a aula, fomos apresentados ao conceito de sistemas especialistas, que buscam mimetizar o "comportamento" de um especialista trilhando uma "árvore de decisão" de modo a obter respostas finais precisas e consistentes. Exemplos: Sistemas eletrônicos para regulagem de motores automotivos, que captam através de sensores os parâmetros de funcionamento de um motor e indicam os ajustes que precisam ser feitos. Ou o caso da malária (este sem o adjutório de recursos eletrônicos): a malária é doença comum na região norte/centro-oeste do país, mas a partir da década de 50 foi praticamente erradicada no sul/sudeste. Com as migrações internas, a malária reapareceu recentemente nestas últimas, mas frequentemente não é diagnosticada devido à falta de experiência dos médicos da região com a doença. Preocupado, o Ministério da Saúde reuniu um painel de especialistas em malária, na Fundação Oswaldo Cruz, para que estes desenvolvam um protocolo para diagnóstico da doença. O protocolo (ainda a ser publicado) consiste basicamente numa "árvore de decisão", com perguntas e testes norteando o diagnóstico. A folha de protocolo (com procedimentos do tipo se febre>39º então prossiga ; se febre ocorre de 3 em 3 dias então prossiga ; etc) pode ser considerada um "sistema especialista": permite a não-especialistas alcançar um diagnóstico correto, emulando os procedimentos de um especialista.

[10] XML

Hoje nossa turma foi apresentada às linguagens de marcação (Markup Languages), que usam tags (rótulos, marcadores) para instruir sobre o quê se deseja fazer com um determinado dado.

Começamos direto com a XML (eXtensible Markup Language), uma linguagem de marcação parecida em alguns aspectos com a HTML (Hyper Text Markup Language) porém mais poderosa e flexível, no que se propõe a fazer, com tags de livre definição. A XML foi desenvolvida para descrever e transportar dados entre nós da rede (internet ou outra), enquanto a HTML está mais voltada para a exibição de dados. A aplicação de estilos e firulas aos dados pode ser especificada com o uso da XSL (eXtensible Stylesheet Language)

Numa descrição abreviada, você: diz como quer estruturar, envelopar e transportar seus dados, com a XML ; diz como quer que eles sejam "embelezados" para apresentação, com a XSL ; mostra afinal na sua página da internet, com a HTML.

Fizemos alguns exercícios (nosso grupo, como de praxe, loosely envolving Juan, Renan, Tissiana e eu) estruturando dados com XML, que envolveram uma fase conceitual de observá-los inicialmente no velho modelo de "árvore invertida".

A "beleza" das linguagens de marcação, me parece, está em usar um arcabouço primitivo de extrema simplicidade (caracteres e arquivos texto) para obter resultados e soluções complexos. Isto cria uma razoável independência de protocolos, sistemas operacionais, hardware, etc. Afinal, "todo mundo" é capaz de gerar, ler e carregar ASCII!

Por fim, a professora nos deu o "caminho das pedras" para solucionar os problemas com a base de dados da clínica médica, apresentando uma consulta SQL que permite recuperar dados em diferença entre duas tabelas.

Ah! Em tempo: bem vindos ao Miss Blog 2007, que vai escolher uma (um?) digna representante das blogueiras (blogueiros?) fucapianas.

[9] Banco de Dados - III

Voltamos ao problema da montagem do banco de dados para a marcação de consultas de uma clínica médica, abordando-o agora à luz dos novos conhecimentos adquiridos ao longo das duas últimas aulas.

A definição dos dados a serem guardados e tabelas a serem montadas foi relativamente sopa-no-mel. A estruturação dos relacionamentos e montagem de consultas para mera visualização dos dados inseridos também pode ser classificada na categoria mamão-com-açúcar.

A coisa emperrou seriamente quando chegamos à fase de construir consultas SQL para recuperar e manipular os dados armazenados de forma que se mostrasse útil para os usuários finais do sistema (em especial a secretária e o paciente). Eu, Juan, Renan e Tissiana quebramos a cabeça, sem chegar a uma solução satisfatória.

O banco de dados obtido como produto final é responsabilidade minha. Será entregue para a professora e pode ser muito útil como exemplo de violações e transgressões às normas do modelo relacional. O pior é que não está funcionando!

De qualquer forma, valeu para o aprendizado de como é importante, mesmo para bancos de dados aparentemente simples, o esmiuçamento do problema na fase conceitual e uma detalhada e documentada estipulação do modelo relacional.

O mais valioso destas aulas foi visualizar as diferenças entre ferramentas. Por que usar um SGBD no lugar de uma planilha eletrônica? Deu pra notar que o SGBD é ferramenta mais adequada quando uma coleção de dados tem perspectiva de vir a ser muito grande, e seja atualizada constantemente.

Além disso, e mais importante: é uma ferramenta que permite diferentes formas de recuperação, visualização e manipulação dos dados sem que seja necessário alterar a estrutura onde os mesmos estão guardados (desde que estas estruturas tenham sido adequadamente especificadas e montadas).

[8] Banco de Dados - II

Querido diário

Hoje demos continuidade ao nosso aprendizado sobre o Access.

Aprendemos sobre o uso da SQL como linguagem para consulta e manipulação de um banco de dados. Usamos um "banco de testes" preparado pela professora com um sistema de reservas para companhias aéreas.

Vimos sobre o uso das cláusulas SELECT, FROM, INNER JOIN e WHERE da SQL, e de alguns operadores como AND e IN, nas consultas de seleção.

Nota 1: Levar uma caixa de bombons pra Márcia.

Vimos também o uso das cláusulas UPDATE e SET para consultas de atualização e INSERT INTO para consultas acréscimo.

Nota 2: Levar uma caixa de bombons E um buquê de flores pra Márcia.

[7] Banco de Dados - I

Querido diário

Hoje nossa turma foi conduzida ao laboratório de informática pela Profª Renata, e apresentada pela primeira vez (ou a primeira vez para a maioria da turma, pelo menos) ao Access - o sistema gerenciador de bancos de dados de uso geral da Microsoft.

Nosso objetivo, conforme colocado pela professora, será desenvolver um banco de dados para a marcação de consultas de uma pequena clínica com quatro médicas de diferentes especialidades. Não deve ser difícil. Afinal, a Márcia, secretária do meu dentista, faz isso todo dia só com a ajuda de uma pequena agenda, um lápis e uma borracha.

A professora ficou tentando nos fazer perder tempo discutindo e montando um modelo conceitual para os dados. Mas nós não estávamos dispostos a perder tempo com tais detalhes: o negócio é meter logo a "mão na massa"!

Recebemos então as primeiras noções sobre o uso do Access, com apresentação das telas do mesmo.

Depois aprendemos sobre a definição de Tabelas (onde os dados serão guardados), os campos que formam seus registros, características de cada tipo de campo, definição de chaves primárias, secundárias e estrangeiras.

Definidas as tabelas, aprendemos sobre como estabelecer os relacionamentos entre as mesmas, através das chaves.

Nota 1: A professora tinha razão. Devíamos ter perdido mais tempo com o maldito modelo conceitual.
Nota 2: Convidar a Márcia pra jantar - ela é muito mais inteligente do que eu imaginava!

[6] E-Commerce

Cada vez mais os atos imemoriais de comprar e vender vem encontrando um poderoso aliado na grande rede. Nem sempre é prático, algumas vezes é mais caro do que na loja da esquina, receber a mercadoria pode ser demorado, mas a verdade é que pode-se comprar e vender de quase tudo através da Internet.

Pensar em comércio eletrônico traz logo à lembrança a Amazon.com, possivelmente a primeira organização a galvanizar a atenção de consumidores e realizar vendas de varejo em volume quantitativo significativo na Internet. Começando como uma livraria virtual, aplicou seu bem sucedido modelo, de "entreposto" entre leitores sequiosos e editoras, a outros segmentos e hoje disponibiliza a venda, além dos livros, de CD's, eletro-eletrônicos, roupas, enfeites, móveis e mais uma série enorme de produtos.

O modelo implementado pela Amazon procura reduzir os custos e esforços de busca por parte dos consumidores, disponibiliza uma pletora de informações sobre os produtos, tentando suprir a necessidade de experimentação dos compradores (oferecendo, por exemplo, um mecanismo de "folhear virtual" dos livros), cuida de construir e manter escrupulosamente a reputação de entregar o que promete, preserva obssessivamente os aspectos de segurança na transação e preocupa-se com os aspectos logísticos da operação comercial (em parceria com FedEx e DHL, gigantes do ramo).

O modelo Amazon fez escola, e é base para outras lojas virtuais como, no Brasil, Americanas.com e Submarino (ambas controladas hoje em dia pelo grupo Americanas). Superadas as dificuldades iniciais que, no Brasil, incluíam serem poucos os consumidores com acesso à Internet e menos ainda os que dispunham de cartão de crédito (o meio de pagamento ubíquo na Internet), as lojas virtuais vem apresentando a cada ano expressivos aumentos de vendas.

A existência de lojas virtuais levou ao surgimento de sites como o Buscapé e o Bondfaro, buscadores que comparam preços e ofertas em várias lojas concomitantemente. Estes sites ainda padecem de certa desconfiança dos consumidores, pois estão longe de ser "independentes", apresentando comparações somente entre lojas a eles afiliadas (e que lhes pagam uma taxa de manutenção... ).

Numa comunidade pulverizada como é a Internet, não demoraram a surgir sites que colocavam consumidores, vendedores particulares e pequenos comerciantes em contacto. Ebay e MercadoLivre se estabeleceram como verdadeiros balcões de leilões virtuais. Apesar do inegável sucesso na parte relativa a colocar compradores e vendedores em contacto direto, estes sites ainda tem seu calcanhar de Aquiles nos aspectos de segurança e confiabilidade, mas vem procurando suprir esta deficiência disponibilizando, por exemplo, um histórico com a reputação dos vendedores e introduzindo meios de pagamento mais seguros para os compradores (como PayPal e Sedex-a-cobrar).

Como suporte aos que desejavam instalar suas lojas virtuais, apareceram então os desenvolvedores de ferramentas especializadas para a criação de sites de comércio online, como o Fast Commerce, por exemplo. Estas ferramentas podem até não ser as ideais para determinados propósitos, mas são certamente um bom e prático ponto inicial.

Pergunta do Renan

Como o e-comerce minimiza os custos de transação para o consumidor ?

Renan

Inicialmente vamos dar uma breve explicação à profª Renata, que a essa altura deve estar seriamente preocupada e curiosa com esta nossa aparente fixação em custos de transação.

Professora, estes custos são a representação dos esforços incorridos por participantes de uma transação à luz da Teoria da Firma (ou Teoria das Agências). Esta teoria propõe que todas as organizações podem ser visualizadas como uma rede de indivíduos trocando entre si bens, serviços e informações pertinentes a estas trocas. Do contacto entre "nós" (knots em inglês) desta rede nascem contratos, explícitos e/ou implícitos, que respaldam as trocas pretendidas. Eu, particularmente, procuro chamar estes nós de elos, para evitar confusão com o pronome. Estes elos são ocupados por indivíduo(s) denominados agentes. Dois agentes, uma vez em contacto, visando realizar uma transação, geralmente não possuem toda a informação sobre os atributos de itens envolvidos na transação, de forma uniforme e total: o vendedor, por exemplo, vai procurar disponibilizar e ressaltar as informações sobre as boas qualidades do produto e esconder informações sobre falhas e defeitos. O comprador, por sua vez, não tem facilmente todas as informações sobre o produto e, mesmo que as tivesse, acabaria por não usá-las devido à sua racionalidade limitada. À diferença de conhecimento sobre os atributos de um produto envolvido em uma transação chamamos de assimetria informacional. No caso exemplificado é do interesse do vendedor manter esta assimetria, e ao comprador interessa quebrá-la. Os custos de transação, portanto, representam os esforços e sacrifícios (monetários ou não) envolvidos na quebra ou manutenção da assimetria informacional, além daqueles incorridos na obtenção inicial, manutenção e preservação da informação. Um corolário presente na teoria, é de que existe um custo de oportunidade envolvido: o custo para obtenção, manutenção ou mesmo supressão de uma informação só se justifica quando se torna menor do que o custo de oportunidade (representado pelo custo de manter-se o status quo, não fazer nada). Não custa (sem trocadilho!) lembrar que tais custos não envolvem apenas valores monetários. Envolvem também valores éticos, morais, filosóficos e dependem também da percepção de cada agente sobre os mesmos.

Podemos então começar nossas reflexões sobre o tema proposto lembrando do artigo do Mario Rese que estudamos em Marketing com o prof. André Aquino. A escolha dos consumidores por produtos e/ou serviços implica (relembrando em pouquíssimas palavras) em custos de transação que envolvem atributos de busca (achar o produto), uso e experimentação (adquirir conhecimento do produto, de suas qualidades e deficiências) e reputação do vendedor (formar uma opinião sobre a probabilidade de uma experiência repetir-se).

Para o e-commerce minimizar os custos referentes a atributos de busca é fácil: ele disponibiliza ao consumidor, do conforto de sua casa, acesso imediato a variadas ofertas de fornecedores. Podem não ser todas as ofertas (o Buscapé, por exemplo, só disponibiliza consultas a lojas afiliadas), mas dependendo da percepção do consumidor e devido à racionalidade limitada, podem ser satisfatórias e suficientes.

Já os custos de experimentação constituem um "calo" nas pretensões do e-commerce: a experiência virtual, por mais informação que você agregue, nem sempre consegue suprir o contacto com o bem ou serviço real. Porém, se o produto já é conhecido do consumidor, este atributo pode perder relevância para a decisão de compra pelo mesmo.

E a reputação do vendedor precisa ser construída através da repetição de experiências bem sucedidas de compra, ou ser avalizadas por prepostos independentes em quem o consumidor confie.

A decisão em favor do comércio virtual, em detrimento da velha e conhecida loja da esquina, vai depender da percepção do consumidor sobre quanto o custo global da transação virtual economiza para o mesmo, em termos de busca, qualidade e adequação do produto obtido, preço do produto e capacidade do fornecedor em fornecer aquilo que promete, em relação à transação já conhecida com o comércio físico.

Ou seja, e-commerce não é mera questão de preços adequados. Reduzir o custo de transação para o consumidor, levando-o a optar pelo e-commerce, envolve ser fácil descobrir o preço oferecido, ter como avaliar o produto à distância, ter segurança na transação e confiança de que os resultados da transação serão os esperados e prometidos.