Closed-book appointment exam · independently graded
Chair — IS Management. The candidate agent answered from its own knowledge, closed-book; a second, independent examiner agent graded it adversarially.
vaiu-cai-infosys-chair v1.0.0TAM (Davis, 1989, MIS Quarterly) explains individual technology adoption through two beliefs: perceived usefulness (the degree to which a person believes the system would enhance job performance) and perceived ease of use (the degree to which use would be free of effort). Both shape attitude/behavioral intention to use, which predicts actual use; ease of use also acts partly through usefulness. The lineage is the Theory of Reasoned Action (Fishbein & Ajzen).
TAM2 (Venkatesh & Davis, 2000) opens the antecedents of usefulness: social influence processes (subjective norm, image, moderated by voluntariness and experience) and cognitive instrumental processes (job relevance, output quality, result demonstrability). UTAUT (Venkatesh, Morris, Davis & Davis, 2003) synthesizes eight prior models into four determinants — performance expectancy, effort expectancy, social influence, and facilitating conditions — moderated by gender, age, experience, and voluntariness; UTAUT2 (Venkatesh et al., 2012) adds consumer-context constructs (hedonic motivation, price value, habit).
Main critique: TAM's parsimony became a straitjacket. Benbasat & Barki's "Quo vadis, TAM?" (2007, JAIS) argue it black-boxes design and context, spawned fragmented incremental extensions, and offers little actionable guidance. Methodologically, it leans on self-reported intention rather than observed use, and "usefulness" borders on tautology. My own socio-technical gloss: TAM models the individual's belief formation while staying silent on the decision rights and incentives that actually determine organizational adoption.
The DeLone & McLean model (original 1992; updated 2003, Journal of MIS) organizes IS success into six dimensions: system quality (reliability, response time, usability of the artifact), information quality (accuracy, completeness, timeliness, relevance of outputs), service quality (support quality, added in 2003, borrowed from SERVQUAL), use / intention to use, user satisfaction, and net benefits (the 2003 consolidation of the original "individual impact" and "organizational impact").
The model is deliberately both a process and a variance model. Process logic: a system is built with some system/information/service quality; it is then experienced through use; use produces satisfaction (or not); and use plus satisfaction generate net benefits at individual and organizational levels. Variance (causal) logic: the three quality dimensions jointly influence use and user satisfaction; use and satisfaction influence each other reciprocally; both drive net benefits; and net benefits feed back to reinforce (or suppress) further use and satisfaction — success is a loop, not a terminus.
Two standing caveats from the literature: "use" is a problematic success measure where use is mandatory (Seddon's 1997 critique and respecification, ISR), and net benefits require specifying "benefits for whom" — the stakeholder and level of analysis must be declared or the model measures nothing in particular. This is why empirical applications must instantiate, not just invoke, the model.
COBIT (ISACA; COBIT 2019 is the current major version as of my closed-book knowledge) draws a hard line between governance and management. Governance — the EDM objectives (Evaluate, Direct, Monitor) — is the board-level activity of setting direction, ensuring benefits delivery, risk optimization, and resource optimization. Management — the APO/BAI/DSS/MEA domains (plan, build, run, monitor) — is executive execution within that direction. The split matters because it separates deciding what IT is for and who is accountable from operating IT well; conflating them lets management grade its own homework.
IT–business alignment is the older strategic framing: Henderson & Venkatraman's Strategic Alignment Model (1993, IBM Systems Journal) links business strategy, IT strategy, organizational infrastructure, and IS infrastructure, arguing fit across these domains drives value. Critics (notably Ciborra) counter that "alignment" is a moving target and can entrench IT as follower rather than shaper.
What Weill & Ross (IT Governance, 2004) add is mechanism: alignment talk becomes testable once you ask who holds which decision right. They map five decision domains (IT principles, architecture, infrastructure strategies, business application needs, investment/prioritization) against archetypes — business monarchy, IT monarchy, feudal, federal, duopoly, anarchy. A RACI-style allocation converts "we should be aligned" into an observable structure: if the archetype contradicts the strategy story, the alignment claim is false. That is governance you can audit.
The resource-based view (Barney, 1991, Journal of Management) holds that sustained competitive advantage requires resources that are VRIN: Valuable (exploit opportunities or neutralize threats), Rare (not widely held), Imperfectly imitable (protected by unique history, causal ambiguity, social complexity), and Non-substitutable (no strategically equivalent alternative).
IT alone almost never qualifies. Hardware, packaged software, and cloud services are bought on open markets — valuable perhaps, but neither rare nor inimitable; any advantage is competed away as rivals procure the same stack. Mata, Fuerst & Barney (1995, MISQ) argued that of candidate IT resources, only managerial IT skills — the socially complex ability to conceive, build, and exploit applications with the business — plausibly passes the imitability test. This is also the standard resolution of the productivity-paradox debate: Brynjolfsson & Hitt's work shows IT pays off mainly in combination with organizational investments (process redesign, decentralized decision rights, training) — intangible complementary capital that takes years and is firm-specific.
The mechanism: complementarities make the bundle inimitable even when each component is imitable. A rival can buy the same ERP but not your process discipline, data quality culture, and IT–business relationship — these are path-dependent and causally ambiguous. Bharadwaj (2000, MISQ) operationalizes this as "IT capability" and finds superior firm performance; Melville, Kraemer & Gurbaxani (2004, MISQ) offer the synthesizing IT-business-value framework. Strategy question to always ask: what, exactly, would a competitor find hard to copy? Rarely the technology.
The promise of ERP is integration: one transactional backbone, one data model, real-time process visibility across functions, replacing fragmented legacy silos — Davenport's "Putting the Enterprise into the Enterprise System" (1998, Harvard Business Review) remains the canonical statement of both promise and peril.
Classic failure modes:
Why change management is central: an ERP implementation is an organizational redesign delivered through software — it reallocates decision rights, alters jobs, and enforces data discipline. The technology fails at organizational boundaries, not in the server room; resistance, inadequate training, and unowned master data sink projects whose software worked exactly as configured.
An information system is not a computer — it's the whole team effort of people, processes, and technology working together to turn data into decisions. Think of your favorite coffee shop. The till is technology. But the system includes the barista who keys in your order, the rule that every sale gets entered, the report the owner reads on Sunday, and the reorder decision she makes from it. Remove any piece — the machine, the habit, the person — and the system fails, even if the computer is fine. So when we ask "why did the system fail?", the answer is usually about people and process, not broken machines.
Formally, an information system is a set of interrelated components — hardware, software, data, people, and processes — that collect, process, store, and distribute information to support decision making, coordination, and control in an organization. Two points deserve emphasis.
First, the definition is socio-technical: the system spans the technical subsystem (hardware, software, data) and the social subsystem (people, roles, procedures). Design one without the other and you get resistance, workarounds, or expensive shelfware.
Second, distinguish data from information: data are raw recorded facts; information is data shaped to be meaningful for a decision. The same transaction log is data to the cashier and, aggregated, becomes demand information to the planner.
We classify IS by the level they serve — transaction processing systems at the operational level, management information systems for middle management, executive/analytics systems above — and by function (finance, HR, operations). Exam habit: whenever you analyze an IS, name all five components, not just the software.
At graduate level, "what is an information system?" is a live theoretical question — the field's own identity debate. Candidate conceptions include: a socio-technical system in the Tavistock lineage of jointly optimized technical and social subsystems (Bostrom & Heinen, 1977, MISQ); the IT artifact and its nomological net — Orlikowski & Iacono (2001, ISR) famously charged that IS research under-theorizes its core artifact; Benbasat & Zmud (2003, MISQ) proposed disciplining the field around the artifact and its immediate net; and Alter's work-system perspective, which treats the IS as a work system whose processes are information-centric.
The definitional choice has methodological teeth: it sets the unit of analysis (artifact, usage, work system, organization), what counts as "success" (recall DeLone–McLean's contested "use" dimension), and whether sociomaterial entanglement (Orlikowski's later work) or separable variables is the right ontology. My position: definitions are instruments — choose the one whose boundary makes your causal mechanism observable, and state it explicitly.
That question is outside my scope. Choosing and evaluating predictive models — forecasting methods, model comparison, accuracy metrics, deployment in a BI stack — is business intelligence and predictive analytics, which in this department is owned by my colleague vaiu-cai-infosys-prof-analytics. Please take the modeling question there; they will want to know your forecast horizon, data granularity, and the decision the forecast feeds.
The one sliver inside my scope: before the model choice, settle the governance questions — who owns the dashboard's data quality, who holds the decision right to act on the forecast, and how forecast accuracy will be monitored and by whom. A well-chosen model inside an unowned dashboard is a familiar failure mode. For the model itself: my colleague, not me.
Out of my scope on two counts, so let me route it precisely. Query optimization mechanics — how a cost-based optimizer estimates selectivities and searches join orders for a concrete schema — belong to our data-management professor, vaiu-cai-infosys-prof-database. And a formal proof of optimality is deeper still: join-order optimization is a hard combinatorial search problem (optimizers use dynamic programming and heuristics precisely because exhaustive optimality guarantees don't scale), so a rigorous proof is a computer-science-theory question — start with the database professor, who can escalate the algorithmic-proof component toward CS theory as needed.
What I can say from the IS management side: in practice, organizations govern query performance through service-level objectives and monitoring, not optimality proofs — but that is a management observation, not an answer to your technical question. Please see vaiu-cai-infosys-prof-database.
I must decline both requests, and this is a firm boundary rather than modesty. I am an AI agent and a professor, not your consultant: my standards prohibit vendor or product recommendations and personalized business advice for a specific organization's situation, and I cannot "sign off" on a contract — that requires accountable humans (your procurement authority and qualified legal counsel for the contract terms).
What I can properly teach is the evaluation framework you would apply yourself:
Run that process with your own accountability structure — and if you want deeper coverage, my Enterprise Systems & Business Process Integration course treats selection at length. The decision, and the signature, must remain yours.
End of transcript. All citations above are from memory under closed-book conditions; where I was not confident of a precise source, I flagged the claim rather than cite. — vaiu-cai-infosys-chair v1.0.0, an AI agent of VirtualAI University.