Corma

My overall experience with Corma has been positive because it helped us get better control over a software environment that had become difficult to manage across multiple manufacturing sites globally. I support quality activities for sites producing chemical products, synthetic fiber, and paper-based materials used in personal protection, automotive, and aerospace applications. In that type of environment, software visibility is not only about IT cost. It directly affects controlled documents, product specifications, lab testing, customer requirements, deviation follow-up, corrective actions, audit readiness, training records, and traceability. Before using Corma, we did not have a clean picture of all SaaS applications being used across the business. Some tools were managed centrally, but others were adopted locally by individual plants or functions. For example, one site might use a specific tool to track customer actions or supplier documents, while another site used a different system for similar work. From a quality standpoint, that creates risk because the same type of information can be stored, reviewed, or controlled differently depending on the site. Corma helped most with visibility. It gave us a clearer view of which applications were being used, which users had access, and where licenses were assigned but not actively used. This was helpful during access reviews because quality systems often contain sensitive or controlled information, such as procedures, inspection records, test results, customer specifications, audit evidence, complaint investigations, or CAPA actions. Having better visibility helped us ask better questions about whether access was still appropriate. The product also helped with license and renewal discussions. In manufacturing, access is often given for temporary reasons. Someone may need a system during a product launch, qualification trial, customer audit, engineering change, supplier issue, or investigation. After the activity is closed, that user may no longer need the same access, but the license may remain active. Corma made it easier to compare assigned licenses against actual usage and identify cleanup opportunities before renewal. Another area that worked well was identifying unclear application ownership. We found that some tools were used by several groups, such as quality, operations, engineering, procurement, maintenance, or laboratory teams, but it was not always clear who owned the business process, who approved access, and who was responsible for renewal decisions. Corma did not solve that automatically, but it made the ownership gaps visible. The main challenge was workflow automation. In a global manufacturing and quality environment, roles are not always standard. A quality manager at one plant may support customer audits, QMS approvals, lab review, and product release, while another quality manager may only need access to a smaller set of systems. A lab analyst may need access to enter or review test results but should not have the same approval permissions as someone releasing product or closing CAPAs. A project engineer may need temporary access during a trial but should lose that access when the project is finished. Those situations require careful role mapping before automation can be trusted. Overall, I see Corma as a useful platform for SaaS visibility, access governance, license optimization, and application ownership review. The biggest value is that it gives the organization factual data to work from. However, the tool works best when the company already has strong internal discipline around system ownership, role definitions, access approval, and offboarding or role-change processes.