下载PDF
Business Continuity in the Cloud: Takeda Pharmaceutical Company's Remote Access Scaling
技术
- 应用基础设施与中间件 - 事件驱动型应用
- 网络安全和隐私 - 网络安全
适用行业
- 药品
- 电信
适用功能
- 产品研发
用例
- 远程控制
- 篡改检测
服务
- 云规划/设计/实施服务
- 硬件设计与工程服务
挑战
武田制药公司是全球历史最悠久的制药公司,在与 Shire PLC 合并后面临重大挑战。此次合并导致网络架构“相当脱节”,需要进行整合和保护。该公司的 IT 团队由首席信息安全官 Mike Towers 领导,负责管理遍布 110 个国家/地区的 70,000 多名员工的系统。该公司已于 2018 年底开始推出 Zscaler Internet Access (ZIA),以通过云保护员工的互联网出口并提供一致的用户体验。然而,此次合并加速了武田向云的迁移,推动该公司尽快转向零信任、用户到目的地模式。挑战在于通过本地互联网分流为每种类型的员工提供安全的员工连接,同时在所有地点保持一致的政策。
关于客户
武田制药公司是一家总部位于东京的制药公司,被认为是世界上最古老的制药公司。该公司在全球拥有举足轻重的影响力,在 110 个国家/地区的 575 个地点拥有超过 52,000 名员工。武田 (Takeda) 2019 年收购 Shire PLC,将其足迹扩展到全球 60 多个办公和研究地点。该公司的 IT 团队位于马萨诸塞州剑桥,为其全球 70,000 多名员工管理系统。武田是一家价值观驱动的公司,注重内部开发以及专有技术、应用程序和知识产权的使用。
解决方案
武田采用 ZIA 进行标准化,取代了其“下一代”防火墙。这为公司提供了更大的灵活性,可以实现安全的员工连接。Zscaler 基于策略的管理控制帮助武田变得更加敏捷,使公司无论员工身在何处都能保持一致的政策。2019 年,武田开始推出 Zscaler Private Access (ZPA),以提供与内部资源的安全连接。这对公司来说是一个重大的文化变革,但它使武田能够扩展远程访问并淘汰 VPN 硬件。该公司改变了控制和配置方法,专注于为员工提供完成工作所需的应用程序,而不是这些应用程序所在的位置。当 2020 年初冠状病毒爆发时,武田能够迅速转向 ZPA,使公司能够安全过渡到完全远程运营。
运营影响
数量效益
相关案例.
Case Study
Case Study: Pfizer
Pfizer’s high-performance computing software and systems for worldwide research and development support large-scale data analysis, research projects, clinical analytics, and modeling. Pfizer’s computing services are used across the spectrum of research and development efforts, from the deep biological understanding of disease to the design of safe, efficacious therapeutic agents.
Case Study
Fusion Middleware Integration on Cloud for Pharma Major
Customer wanted a real-time, seamless, cloud based integration between the existing on premise and cloud based application using SOA technology on Oracle Fusion Middleware Platform, a Contingent Worker Solution to collect, track, manage and report information for on-boarding, maintenance and off-boarding of contingent workers using a streamlined and Integrated business process, and streamlining of integration to the back-end systems and multiple SaaS applications.
Case Study
Process Control System Support
In many automated production facilities, changes are made to SIMATIC PCS 7 projects on a daily basis, with individual processes often optimised by multiple workers due to shift changes. Documentation is key here, as this keeps workers informed about why a change was made. Furthermore, SIMATIC PCS 7 installations are generally used in locations where documentation is required for audits and certification. The ability to track changes between two software projects is not only an invaluable aid during shift changes, but also when searching for errors or optimising a PCS 7 installation. Every change made to the system is labour-intensive and time-consuming. Moreover, there is also the risk that errors may occur. If a change is saved in the project, then the old version is lost unless a backup copy was created in advance. If no backup was created, it will no longer be possible to return to the previous state if and when programming errors occur. Each backup denotes a version used by the SIMATIC PCS 7 system to operate an installation. To correctly interpret a version, information is required on WHO changed WHAT, WHERE, WHEN and WHY: - Who created the version/who is responsible for the version? - Who released the version? - What was changed in the version i.e. in which block or module of the SIMATIC PCS 7 installation were the changes made? - When was the version created? Is this the latest version or is there a more recent version? - Why were the changes made to the version? If they are part of a regular maintenance cycle, then is the aim to fix an error or to improve production processes? - Is this particular version also the version currently being used in production? The fact that SIMATIC PCS 7 projects use extremely large quantities of data complicates the situation even further, and it can take a long time to load and save information as a result. Without a sustainable strategy for operating a SIMATIC PCS 7 installation, searching for the right software version can become extremely time-consuming and the installation may run inefficiently as a result.
Case Study
Vodafone Hosted On AWS
Vodafone found that traffic for the applications peak during the four-month period when the international cricket season is at its height in Australia. During the 2011/2012 cricket season, 700,000 consumers downloaded the Cricket Live Australia application. Vodafone needed to be able to meet customer demand, but didn’t want to invest in additional resources that would be underutilized during cricket’s off-season.